Well while developing a web application that allow users to draw graphs (flow charts, ER diagram , UML, .... etc) the information of drawn items and their relation to each other and position on canvas is expressed as JSON object

The question is:

1- is saving such graph in database as raw (json object text) is enough (in one field of a table)
2- or is it always required to break down the json object into logical pieces and store them into a well built database structure!

option 1- other than making devilopers life easier it will eleminate the need of recreating json object from small bits and pieces of information when the user open a graph he have built and saved long time ago

option 2- will have fine grain details in proper structure but will cost kind of heavy processing while opening a saved graph from Database

which way is correct way to go ?

The best way to ask is probably to the people working on it; exactly what I did!

Tl;dr: it was originally there before make and &{}, and it's still the function to use in some situations.

Basically, here are the most important parts quoted:


  
    So what's the reasoning behind new ? Is it something useful ? Should we 
    use it ? 
  
  
  You cannot do this without new 


v := new(int)
*v++
fmt.Println(*v)



  new isn't a headline feature of Go, you won't find it used often, but 
  when you need it, it is there. 
  
  Cheers 
  
  Dave


After another answer showing this kind of solution:

vv := 0
v := &vv
*v++
fmt.Println(*v)


I asked for further clarification:


  
    So basically, Dave's point doesn't really stand?
  
  
  There are places where it's inconvenient to sneak in a new
  variable just to take its address.
  
  new(T) has an immediately straightforward meaning, rather than
  being a multi-step idiom.
  
  Dave's point only falls if mere technical possibility (of doing without
  new) is compelling on its own.  
  
  
    Wasn't this discussed because it was just obvious that Go should have it because almost every language has it?
  
  
  The "shall we keep new?" discussion pops up from time to time.
  Since we can't take it out until Go 2, if I understand the Promise correctly,
  there doesn't seem to be much to be had from going round the
  loop again; by the time Go 2 is thinkaboutable, we might have some
  different and better ideas ...
  
  Chris


It's also there mostly for historical reasons:


  
    you need to consider the history of the project. i think new is introduced
    first before there is make.
  
  
  That is true.  In fact we struggled for a while before coming up with
  the idea of make.  If you look at the repository logs you can see that
  make only shows up in January 2009, revision 9a924177598f.
  
  The new builtin function also preceded the idea of &{} for taking the
  address of a composite literal (and that syntax is in some sense
  wrong; it probably ought to be (*T){fields of T} but there wasn't
  enough reason to change it).
  
  The new function is not strictly necessary but code does seem to use
  it in practice.  It's hard to get rid of it at this point.
  
  Ian

