Less efficient indexes? Are you talking about space in a db compared to an int for a pointer or are you saying that the time to isolate the data on that row because of the data type of the pointer? The flip side is data insertion.
Can you tell us why you use less efficient? On Mon, Oct 30, 2017 at 9:47 AM, < [email protected]> wrote: > On 2017-10-30 09:28, Stephen Russell wrote: > >> From a design POV why would you want to give up control and have the >>> >> backend responsible for something that takes a reply of, to provide you >> data necessary for the next set of inserts? >> >> PKMasterID you generate via a GUID. >> >> If that same key is required in 2,3,4+ other tables as FKMasterID, why not >> generate the pointer and then submit ALL the inserts at once within a >> transaction on the server? Or do you have procedures on the server that >> do >> your insert and all you need to do is pass the params for them? >> >> > > That's what I liked about the varchar(40) GUID keys I generated in the > app--I could do all that and then save the whole series of datasets > (parent/child/grandchild) with one transaction instead of using > auto-increment integer keys. However, that comes at a cost of course -- > larger indexes, arguably less efficient. > > Like everything, there's trade-offs with each path. > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/cajidmyjn1jm1mqvsx4rpjfeehegc2muonx+ko1kortg66vs...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
