On 01/03/2018 19:05 , Gavin Flower wrote:
> On 02/03/18 06:47, Daevor The Devoted wrote:
>>
>> On Thu, Mar 1, 2018 at 2:07 PM, Rakesh Kumar <rakeshkumar464@aol.com
>> <mailto:rakeshkumar464@aol.com>> wrote:
>>
>>
>> >Adding a surrogate key to such a table just adds overhead,
>> although that could be useful
>> >in case specific rows need updating or deleting without also
>> modifying the other rows with
>> >that same data - normally, only insertions and selections happen
>> on such tables though,
>> >and updates or deletes are absolutely forbidden - corrections
>> happen by inserting rows with
>> >an opposite transaction.
>>
>> I routinely add surrogate keys like serial col to a table already
>> having a nice candidate keys
>> to make it easy to join tables. SQL starts looking ungainly when
>> you have a 3 col primary
>> key and need to join it with child tables.
>>
>>
>> I was always of the opinion that a mandatory surrogate key (as you
>> describe) is good practice.
>> Sure there may be a unique key according to business logic (which may
>> be consist of those "ungainly" multiple columns), but guess what,
>> business logic changes, and then you're screwed! So using a primary
>> key whose sole purpose is to be a primary key makes perfect sense to me.
>
> I once worked in a data base that had primary keys of at least 4
> columns, all character fields, Primary Key could easily exceed 45
> characters. Parent child structure was at least 4 deep.
>
> A child table only needs to know its parent, so there is no logical
> need to include its parent and higher tables primary keys, and then
> have to add a field to make the composite primary key unique! So if
> every table has int (or long) primary keys, then a child only need a
> single field to reference its parent.
>
> Some apparently safe Natural Keys might change unexpectedly. A few
> years aback there was a long thread on Natural versus Surrogate keys -
> plenty of examples were using Natural Keys can give grief when they
> had to be changed! I think it best to isolate a database from
> external changes as much as is practicable.
>
> Surrogate keys also simply coding, be it in SQL or Java, or whatever
> language is flavour of the month. Also it makes setting up testdata
> and debugging easier.
>
> I almost invariably define a Surrogate key when I design tables.
>
>
> Cheers,
> Gavin
>
>
>
>
+5. I fully agree.
---
El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
https://www.avast.com/antivirus
