Следях всички дискусии около статията и честно казано смятам че е прекалено тенденциозна и пресилена. И за пореден път представя едно крайно мнение, базирано на принципи и идеализъм, а не на практическа стойност.

За мен, идеята на АутоИнк е точно да се спести работа на програмиста. Има хиляди начини да се генерират уникални стойности, но няма груг начин, който напълно да елиминира нуждата от каквито и да е познания за начина на генериране. Всичко което един програмист очаква от това поле е точно уникална стойност, бе никаква необходимост от какъвто и да е контрол върху нея, по простата причина че такъв не е необходим - каква е стаийността не е от значение, защото тя не носи никаква информация.

Ето и няколко коментара по основните точки на статията:

1. Не може да се insert-ва произволна стойност в това поле (освен със "специални" разширения на съответната база данни).
2. Не може да се задава начална стойност на това поле, от което да започне генериране.
3. Не може да се генерират стойности с променлива стъпка.
4. Не може да се прескача дадена област от стойности (например стигнал е AutoInc-а до 1000 - не може да се прескочат 2000 стойности и да се продължи от 3000).
Всички точки по-горе сочат че АутоИнк не е полезен защото програмиста няма контрол върху него. Но това е точно идеята - да няма контрол. По този начин никога и никой неможе да въведе грешна стойност, никога и никой неможе да обърка каквото и да било; нови програмисти не трябва да заят нищо за това поле; всичко е чисто и ясно и ако друго приложение трябва да работи с тази база, неговите програмисти знаят какво да очакват от полето. Точно това е силата - в простотата на този вид поле. Когато се работи в екип от много хора, няма нищо по-полезно от твърди стандарти и АутоИнк е точно това - просто концепция която е ясна на всяко хлапе и на всеки ветеран.

Защо въобще бих искал да въведа прозиволна стойност е полето - ако тази стойност няма никакъв смисъл (не носи информация), едно приложение никога не би имало нужда да специфицира стойността.
Защо бих искал да дефинирам начална стойност или стъпка или области - не това е целта на подобно поле. Ако искам да разграничавам записи базирано на области на това поле, много по-добре е да си направя друго поле в таблицата, отколкото да разчитам на странни правила като ИД МОД 5 = 3 или подобни.

5.Всички средства за програмиране изпитват редица проблеми с това че стойноста на полето се генерира от самия сървър. Затова се налага дадения компонент или клас да прави задължително refresh-ване на данните след като са изпратени към сървъра, за да се изтегли генерираната стойност.
Това не е проблем - това е предимство. По този начин базата е цяла. Какво ще стане ако 5 приложения трябва да работят със същата таблица - и 5-те ли ще трябва да генерират стойности по същия начин. Ами е ако публик сървис? Всеки който трябва да работи с таблицата ще трябва предварително да бъде инструктиран по кой точно начин се генерират стойностите.

6.Не е известна стойноста на полето преди то да бъде изпратено към сървъра (това е доста полезно при системи със сложни връзки между различни модули).
Какъв е проблема тук? Защо въобше бих искал да зная стойността преди да е създадена? В случите които искам да я зная, след създаване на записа мога да си я поискам. Това е напълно аналогично с първо поискване на стойността и после въвеждане на записа.

7.Силна зависимост от базата данни. Ако използвате такива полета вашето приложение става силно зависимо от текущата база данни и прехвърлянето на приложението към друг сървър става доста трудно. AutoInc полета има в MS SQL, MS Access и MySQL (доколкото чувам по форумите), но такива полета няма със сигурност в Firebird, Interbase и Oracle (не зная как е положението при DB2).
Добре, а ако реша да мигрирам от Фиребирд, на МССЯЛ, нали МССЯЛ няма да има въпросния генератор? Това не е ли същия (и даже по-голям) проблем?

За мен генераторите имат напълно различен смисъл и не би трябвало да се използват вместо АутоИнк полета. Могат да се използват, но за мен това е чиста загуба на ресурси и създаване на по-голяма възможност за проблеми и по-трудна разбота с базата. В реалния свят, програмисти и потребители на базите се менят прекалено често и колкото повече информция е необходима на един нов програмист да работи с дадена база, толкова по-големи са шансовете за проблеми и толкова по неефективна е системата като цяло.

Редактирано от fiffy на 06.06.05 23:45.