Re: Ама ти си повтаряш като развален грамофон / Компютри и Интернет / Бази данни

Връщам в клуба една дискусия, която се заформи между мен и salle:

Твърдиш, че основнатга задача на auto_increment да генерират уникални стойности (което е оснавна и единствен а задача на UUID финкциите) и не желаеш да възприемеш въобще, че има друга задача която те изпълняват а именно генерирането на последователности

Както се казах (или поне се опитах да кажа) на няколко пъти: Основната цел и на AutoInc и на Генераторите е да дадат уникална стойност в случай на конкурентни транзакции/връзки. Всеки DB сървър гарантира че конкурентни връзки няма да получат еднакво ID дори и в един и същ момент да подадат заявка за генериране на ID.

Четох статията ти и в нея се стараеш да докажеш, че auto_increment нямат никакво приложение.

Както казах в статията Ползвал съм AutoInc колони - не мога да го отрека. Също така не мога да отрека че за простички случаи тези колони си пасват идеално, т.е. не ги отричам - просто казвам къде са идеални за ползване и къде не.

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

Мога да ти дам един пример. Ти самият се съгласяваш, че всеки случай е специфичен и, че дадено решение може да е добро в един случай но неподходящо в друг. В същото време обаче се самоопровергаваш твърдейки, че има "Абсолютно погрешно виждане"

Визирам следния абзац:

"Работех по един проект известно време, където т.нар. project manager си беше втълпил идеята че всяка една таблица трябва да има AutoInc поле! Абсолютно погрешно виждане."

Ами ти противопоставяш едно напълно крайно виждане срещу друго крайно виждане. При това положение с нищо не си по-добър от въпросния мениджър

Ако се замислим по-добре над цитирания абзац, аз лично виждам следния смисъл

: "Абсолютно погрешното виждане" е че всяка таблица се поставя под "общ знаменател" и се казва от този project manager "че ВСЯКА таблица трябва да има AutoInc Ей това е абсолютно погрешното - не можеш всички таблици да ги приравняваш, всяка таблица си има особености и трябва да се преценява според таблицата.

Аз бих казал "Чак пък всяка таблица ..."

По-нататък подкрепяш твърдението си с още по-краен пример:

"Когато една таблица си има "естествена" уникалност в някоя стойност от данните - няма никаква нужда да се добавя още едно поле (AutoInc), което не носи никаква информация в повече. "

На теория си прав. На практика много често има нужда и това е прословутото (практическо) правило на Администраторите на Бази Данни (DBA):

Първо Нормализирай колкото се може повече. След това Денормализирай там където ще спечелиш скорост.

Когато имаш композитен първичен ключ върху няколко стрингови колонки (Някакви имена да речем) тогава добавянего на излишък под формата на уникална целочислена колонка може многократно да ускори работата на заявките.

Напълно съм съгласен

Колкото до генерирането на последователности това е изключително важна задача просто защото има куп "външни" фактори които я изискват включително нормативни и законови. Пример: Номера на фактури, заповеди, служебни бележки, командировъчни и т.н. трябва да са последователни по закон.

Ок, напълно съм съгласен за генерирането на последователности, но основната задача според мен на AutoInc-а и генераторите я написах в началото. (Между другото според доста закони и наредби е проблемно наличието на "дупки" в последователностите. А такива дупки се получават много лесно при AutoInc и генераторите. Затова аз лично не ползвам генератори/AutoInc за местата, където по закон се искат последователни номера без дупки).

"Защо не кажеш нищо за статията ми за лиценза на MySQL?"

Къде е тази статия?

http://cleverdevelopers.blogspot.com/2005/05/open-source.html

Изпаднала е от списъка с recent статии.

"Нещо невярно и непроучено ли съм написал там?"
Интересно ми е къде си проучвал. Честно казано през годините съм изчел тонове глупости по въпроса.
(Работя за MySQL AB от март 2002 а използвам MySQL от 1997)

Проучвал съм от сайта на MySQL, но ти като вътрешен човек ще ме изкоригираш тук там за статията

. Както казах в един друг разговор - коригирал съм в почти всяка публикувана статия след получени коментари от читатели

"Ами статиите ми за Firebird?"
Не разибрам от Firebird а твърдо вярвам, че е непрофесионално да изказваш мнение за нещо което не разбираш. В това отношерние явно имаме големи различия.

Нямаме различия по тази точка, но както винаги съм мразил електронната комуникация - винаги все нещо остава неразбрано от двете страни. Няма нищо по-добро от директния разговор.

Между другото защо изнесе този спор извън клуба? Аз не изпитвам никакви притеснения това което пиша тук да може да се чете от всекиго.
Ето, върнах го. Просто не очаквах че ще продължи дълго разговора

--
Miroslav Penchev

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

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

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

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).
Добре, а ако реша да мигрирам от Фиребирд, на МССЯЛ, нали МССЯЛ няма да има въпросния генератор? Това не е ли същия (и даже по-голям) проблем?

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