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, < mbsoftwaresolutions@mbsoftwaresolutions.com> 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]