> За мен, идеята на АутоИнк е точно да се спести работа на програмиста.
Напълно си прав но това не означава че резултатите ще се по-добри във всички ситуации.
Резултатите са винаги едни и съши - уникален идентификатор на записа (бил той последователен или не).

Това може да бъде вярно (макар че не е задължително) само за изключително прости бази данни.
В такъв случай явно аз не зная какво е сложна база. Работя в частна банка в Чикаго и явно базите ни са прости, зашото нито една не използва генерирани стойности и всички използват АутоИнк! Би ли дефинирал 'сложна база'?

Виж сега - как ще пренебрегваш така това поле - това е най-важното поле от цялата таблица. То ти носи уникалноста на данните в един запис. Как ще merge-неш данни от два (и повече източника) без да контролираш това поле??? Как ще обработиш ситуациите при конкурентен update към един и същ запис без да работиш с това поле??? Тези и много други са все ситуации от реалните системи при многопотребителска работа.
Напротив - това си е съвсем обикновено поле и просто дава уникална стойност за записа (което явно е най-важното за теб). Ако данните трябва да се merge-ват запазвайки едентификатора си, нито АутоИнк нито пък генераторите са добра идея. Ще кажеш с контрол върху генераторите може да гарантираш уникалност и в различните източници (чрез задаване на области или пък стъпка), но това отново е лош дизайн, защото най-малкото трябва да знаеш предварително колко на брой са тези източници и какви са техните лимити. Какъв е проблема с едновременните update-и?

>Това не е проблем - това е предимство. По този начин базата е цяла. Какво ще стане ако 5 приложения трябва да работят със същата таблица - и 5-те ли ще трябва да генерират стойности по същия начин. Ами е ако публик сървис? Всеки който трябва да работи с таблицата ще трябва предварително да бъде инструктиран по кой точно начин се генерират стойностите.
Нямам си и на идея какво искаше да кажеш с това
Искам да кажа че ако има 5 различни приложения които работят с една база, и петте ще трябва да използва същия алгоритъм за генериране на стойности. Т.е. и 5-те ще трябва да знаят кой алгоритъм е бил избран за това поле (като дори няма начин тази информация да се получи от базата).

А как ще insert-неш записи едновременно в няколко таблици, които имат връзки по това поле?
Каква е разликата:
А)
1) ИД = генерирай ИД
2) инсерт в таблица1
3) инсерт в таблица2
4) инсерт в таблица3 ...
Б)
1) инсерт в таблица1
2) вземи генерирано ИД
3) инсерт в таблица2
4) инсерт в таблица3

А в случая в който инсерт-ваш само в една таблица и не те интересува ИД-то:
А)
1) ИД = генерирай ИД
2) инсерт в таблица1
Б)
1) инсерт в таблица1

АутоИнк даже спестява един рекуест до базата.

Единствения проблем е с MSSQL. Но там лесно се симулират генератори. Иначе AutoInc трябва да се симулират в FB, Oracle, DB2 и не знам къде още.
Какъв е проблема - че в МССЯЛ няма същите генератори (които и без това не са АНСИ стандарт)? Има ли същите генератори в базите които си изброил? Не виждам какво е предимството на генераторите тук: и с генератори и с Аутоинк, винаги имаш проблеми при мигрирането.

Тук си в голяма грешка - логическия смисъл и на двете е един и същ: да ти дадат гарантирано уникална стойност, дори и две (и повече) конкурентни връзки да поискат такава стойност в един и същ момент.
Не ми даваш никакви аргументи в полза на това твърдение? Просто го повтаряш отново и отново...

Епа, това е моето хоби...

Съдържаниет е скрито
Влезте за да го видите