AutoInc и Генератори
24 отговора
1054 прегледа
AutoInc и Генератори
Връщам в клуба една дискусия, която се заформи между мен и salle:
Твърдиш, че основнатга задача на auto_increment да генерират уникални стойности (което е оснавна и единствен а задача на UUID финкциите) и не желаеш да възприемеш въобще, че има друга задача която те изпълняват а именно генерирането на последователности
Както се казах (или поне се опитах да кажа) на няколко пъти: Основната цел и на AutoInc и на Генераторите е да дадат уникална стойност в случай на конкурентни транзакции/връзки. Всеки DB сървър гарантира че конкурентни връзки няма да получат еднакво ID дори и в един и същ момент да подадат заявка за генериране на ID.
Четох статията ти и в нея се стараеш да докажеш, че auto_increment нямат никакво приложение.
Както казах в статията Ползвал съм AutoInc колони - не мога да го отрека. Също така не мога да отрека че за простички случаи тези колони си пасват идеално, т.е. не ги отричам - просто казвам къде са идеални за ползване и къде не.
Виж ако беше казал, че в частния случай когато използваш свойството уникалност предимстват аим не са особено големи щеше да е друго. Само, че цялата ти статия е изградена върху пълно отрицание при това тенденциозно именно защото вадиш частния случай от контекста му на такъв и обобщаваш.
Мога да ти дам един пример. Ти самият се съгласяваш, че всеки случай е специфичен и, че дадено решение може да е добро в един случай но неподходящо в друг. В същото време обаче се самоопровергаваш твърдейки, че има "Абсолютно погрешно виждане"
Визирам следния абзац:
"Работех по един проект известно време, където т.нар. project manager си беше втълпил идеята че всяка една таблица трябва да има AutoInc поле! Абсолютно погрешно виждане."
Ами ти противопоставяш едно напълно крайно виждане срещу друго крайно виждане. При това положение с нищо не си по-добър от въпросния мениджър
Ако се замислим по-добре над цитирания абзац, аз лично виждам следния смисъл
: "Абсолютно погрешното виждане" е че всяка таблица се поставя под "общ знаменател" и се казва от този project manager "че ВСЯКА таблица трябва да има AutoInc Ей това е абсолютно погрешното - не можеш всички таблици да ги приравняваш, всяка таблица си има особености и трябва да се преценява според таблицата.
Аз бих казал "Чак пък всяка таблица ..."
По-нататък подкрепяш твърдението си с още по-краен пример:
"Когато една таблица си има "естествена" уникалност в някоя стойност от данните - няма никаква нужда да се добавя още едно поле (AutoInc), което не носи никаква информация в повече. "
На теория си прав. На практика много често има нужда и това е прословутото (практическо) правило на Администраторите на Бази Данни (DBA):
Първо Нормализирай колкото се може повече. След това Денормализирай там където ще спечелиш скорост.
Когато имаш композитен първичен ключ върху няколко стрингови колонки (Някакви имена да речем) тогава добавянего на излишък под формата на уникална целочислена колонка може многократно да ускори работата на заявките.
Напълно съм съгласен
Колкото до генерирането на последователности това е изключително важна задача просто защото има куп "външни" фактори които я изискват включително нормативни и законови. Пример: Номера на фактури, заповеди, служебни бележки, командировъчни и т.н. трябва да са последователни по закон.
Ок, напълно съм съгласен за генерирането на последователности, но основната задача според мен на AutoInc-а и генераторите я написах в началото. (Между другото според доста закони и наредби е проблемно наличието на "дупки" в последователностите. А такива дупки се получават много лесно при AutoInc и генераторите. Затова аз лично не ползвам генератори/AutoInc за местата, където по закон се искат последователни номера без дупки).
"Защо не кажеш нищо за статията ми за лиценза на MySQL?"
Къде е тази статия?
[линк]
Изпаднала е от списъка с recent статии.
"Нещо невярно и непроучено ли съм написал там?"
Интересно ми е къде си проучвал. Честно казано през годините съм изчел тонове глупости по въпроса.
(Работя за MySQL AB от март 2002 а използвам MySQL от 1997)
Проучвал съм от сайта на MySQL, но ти като вътрешен човек ще ме изкоригираш тук там за статията
. Както казах в един друг разговор - коригирал съм в почти всяка публикувана статия след получени коментари от читатели
"Ами статиите ми за Firebird?"
Не разибрам от Firebird а твърдо вярвам, че е непрофесионално да изказваш мнение за нещо което не разбираш. В това отношерние явно имаме големи различия.
Нямаме различия по тази точка, но както винаги съм мразил електронната комуникация - винаги все нещо остава неразбрано от двете страни. Няма нищо по-добро от директния разговор.
Между другото защо изнесе този спор извън клуба? Аз не изпитвам никакви притеснения това което пиша тук да може да се чете от всекиго.
Ето, върнах го. Просто не очаквах че ще продължи дълго разговора
--
Miroslav Penchev
[линк]
Твърдиш, че основнатга задача на auto_increment да генерират уникални стойности (което е оснавна и единствен а задача на UUID финкциите) и не желаеш да възприемеш въобще, че има друга задача която те изпълняват а именно генерирането на последователности
Както се казах (или поне се опитах да кажа) на няколко пъти: Основната цел и на AutoInc и на Генераторите е да дадат уникална стойност в случай на конкурентни транзакции/връзки. Всеки DB сървър гарантира че конкурентни връзки няма да получат еднакво ID дори и в един и същ момент да подадат заявка за генериране на ID.
Четох статията ти и в нея се стараеш да докажеш, че auto_increment нямат никакво приложение.
Както казах в статията Ползвал съм AutoInc колони - не мога да го отрека. Също така не мога да отрека че за простички случаи тези колони си пасват идеално, т.е. не ги отричам - просто казвам къде са идеални за ползване и къде не.
Виж ако беше казал, че в частния случай когато използваш свойството уникалност предимстват аим не са особено големи щеше да е друго. Само, че цялата ти статия е изградена върху пълно отрицание при това тенденциозно именно защото вадиш частния случай от контекста му на такъв и обобщаваш.
Мога да ти дам един пример. Ти самият се съгласяваш, че всеки случай е специфичен и, че дадено решение може да е добро в един случай но неподходящо в друг. В същото време обаче се самоопровергаваш твърдейки, че има "Абсолютно погрешно виждане"
Визирам следния абзац:
"Работех по един проект известно време, където т.нар. project manager си беше втълпил идеята че всяка една таблица трябва да има AutoInc поле! Абсолютно погрешно виждане."
Ами ти противопоставяш едно напълно крайно виждане срещу друго крайно виждане. При това положение с нищо не си по-добър от въпросния мениджър
Ако се замислим по-добре над цитирания абзац, аз лично виждам следния смисъл
: "Абсолютно погрешното виждане" е че всяка таблица се поставя под "общ знаменател" и се казва от този project manager "че ВСЯКА таблица трябва да има AutoInc Ей това е абсолютно погрешното - не можеш всички таблици да ги приравняваш, всяка таблица си има особености и трябва да се преценява според таблицата.
Аз бих казал "Чак пък всяка таблица ..."
По-нататък подкрепяш твърдението си с още по-краен пример:
"Когато една таблица си има "естествена" уникалност в някоя стойност от данните - няма никаква нужда да се добавя още едно поле (AutoInc), което не носи никаква информация в повече. "
На теория си прав. На практика много често има нужда и това е прословутото (практическо) правило на Администраторите на Бази Данни (DBA):
Първо Нормализирай колкото се може повече. След това Денормализирай там където ще спечелиш скорост.
Когато имаш композитен първичен ключ върху няколко стрингови колонки (Някакви имена да речем) тогава добавянего на излишък под формата на уникална целочислена колонка може многократно да ускори работата на заявките.
Напълно съм съгласен
Колкото до генерирането на последователности това е изключително важна задача просто защото има куп "външни" фактори които я изискват включително нормативни и законови. Пример: Номера на фактури, заповеди, служебни бележки, командировъчни и т.н. трябва да са последователни по закон.
Ок, напълно съм съгласен за генерирането на последователности, но основната задача според мен на AutoInc-а и генераторите я написах в началото. (Между другото според доста закони и наредби е проблемно наличието на "дупки" в последователностите. А такива дупки се получават много лесно при AutoInc и генераторите. Затова аз лично не ползвам генератори/AutoInc за местата, където по закон се искат последователни номера без дупки).
"Защо не кажеш нищо за статията ми за лиценза на MySQL?"
Къде е тази статия?
[линк]
Изпаднала е от списъка с recent статии.
"Нещо невярно и непроучено ли съм написал там?"
Интересно ми е къде си проучвал. Честно казано през годините съм изчел тонове глупости по въпроса.
(Работя за MySQL AB от март 2002 а използвам MySQL от 1997)
Проучвал съм от сайта на MySQL, но ти като вътрешен човек ще ме изкоригираш тук там за статията
. Както казах в един друг разговор - коригирал съм в почти всяка публикувана статия след получени коментари от читатели
"Ами статиите ми за Firebird?"
Не разибрам от Firebird а твърдо вярвам, че е непрофесионално да изказваш мнение за нещо което не разбираш. В това отношерние явно имаме големи различия.
Нямаме различия по тази точка, но както винаги съм мразил електронната комуникация - винаги все нещо остава неразбрано от двете страни. Няма нищо по-добро от директния разговор.
Между другото защо изнесе този спор извън клуба? Аз не изпитвам никакви притеснения това което пиша тук да може да се чете от всекиго.
Ето, върнах го. Просто не очаквах че ще продължи дълго разговора
--
Miroslav Penchev
[линк]
Re: AutoInc и Генератори
За тези, които ще прочетат статията за лиценза, но ще пропуснат коментарите към нея - това е цитат от един мой коментар към статията:
Проблема е че MySQL е пуснат под GPL лиценза. А още по-важния проблем е че много хора не разбират (и не знаят) нищо за open source лицензите. Почти всички програмисти са на мнение че щом нещо се нарича Open Source - значи можеш да го вземеш и да правиш каквото си искаш с него. Идеята на статията е да даде пример че това изобщо не е вярно. И в Open Source-а си има лицензни режими, които трябва да се следят и спазват.
--
Miroslav Penchev
[линк]
Проблема е че MySQL е пуснат под GPL лиценза. А още по-важния проблем е че много хора не разбират (и не знаят) нищо за open source лицензите. Почти всички програмисти са на мнение че щом нещо се нарича Open Source - значи можеш да го вземеш и да правиш каквото си искаш с него. Идеята на статията е да даде пример че това изобщо не е вярно. И в Open Source-а си има лицензни режими, които трябва да се следят и спазват.
--
Miroslav Penchev
[линк]
Re: AutoInc и Генератори
по този въпрос аз си чета преди лягане ето това:
[линк]
сега погледнах в един от последните си проекти:
- 8 бр. таблици са с PK autoinc-полета
- 3 бр. са "справочници", от вида (id, name) и няма да се променят никога, и са твърдо зададени в БД. Е, пак са с PK inc-полета, но не "auto".
- 1 бр. е с "естествен ключ", т.е в PK има стойности 101..150, 201..210, 301..330 и т.н. те се генерират от логиката на приложението (само от едно работно място)
- 2 бр. са с композитни PK, и са "междинни" таблици, които служат за връзка между 2 таблици с отношение n:m . Нещо като (idTableLeft, idTableRight, Value)
Чудя се, дали съотношението между бройките на разните видове таблици е правилно? ;)
[линк]
сега погледнах в един от последните си проекти:
- 8 бр. таблици са с PK autoinc-полета
- 3 бр. са "справочници", от вида (id, name) и няма да се променят никога, и са твърдо зададени в БД. Е, пак са с PK inc-полета, но не "auto".
- 1 бр. е с "естествен ключ", т.е в PK има стойности 101..150, 201..210, 301..330 и т.н. те се генерират от логиката на приложението (само от едно работно място)
- 2 бр. са с композитни PK, и са "междинни" таблици, които служат за връзка между 2 таблици с отношение n:m . Нещо като (idTableLeft, idTableRight, Value)
Чудя се, дали съотношението между бройките на разните видове таблици е правилно? ;)
Re: AutoInc и Генератори
Следях всички дискусии около статията и честно казано смятам че е прекалено тенденциозна и пресилена. И за пореден път представя едно крайно мнение, базирано на принципи и идеализъм, а не на практическа стойност.
За мен, идеята на АутоИнк е точно да се спести работа на програмиста. Има хиляди начини да се генерират уникални стойности, но няма груг начин, който напълно да елиминира нуждата от каквито и да е познания за начина на генериране. Всичко което един програмист очаква от това поле е точно уникална стойност, бе никаква необходимост от какъвто и да е контрол върху нея, по простата причина че такъв не е необходим - каква е стаийността не е от значение, защото тя не носи никаква информация.
Ето и няколко коментара по основните точки на статията:
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).
Добре, а ако реша да мигрирам от Фиребирд, на МССЯЛ, нали МССЯЛ няма да има въпросния генератор? Това не е ли същия (и даже по-голям) проблем?
За мен генераторите имат напълно различен смисъл и не би трябвало да се използват вместо АутоИнк полета. Могат да се използват, но за мен това е чиста загуба на ресурси и създаване на по-голяма възможност за проблеми и по-трудна разбота с базата. В реалния свят, програмисти и потребители на базите се менят прекалено често и колкото повече информция е необходима на един нов програмист да работи с дадена база, толкова по-големи са шансовете за проблеми и толкова по неефективна е системата като цяло.
За мен, идеята на АутоИнк е точно да се спести работа на програмиста. Има хиляди начини да се генерират уникални стойности, но няма груг начин, който напълно да елиминира нуждата от каквито и да е познания за начина на генериране. Всичко което един програмист очаква от това поле е точно уникална стойност, бе никаква необходимост от какъвто и да е контрол върху нея, по простата причина че такъв не е необходим - каква е стаийността не е от значение, защото тя не носи никаква информация.
Ето и няколко коментара по основните точки на статията:
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 на
Re: AutoInc и Генератори
Сега се сещам, че бях мяркал тази твоя статия, но просто тя попадна в кюпа на "многото"
Радвам се, че поне схващаш същността на GPL много по-добре от доста хора. За съжаление дори защитниците на GPL не винаги са наясно с него.
Колкото до изненадата ти от [линк] тя само показва, че не си проучил нещата преди да пишеш
За съжаление...
Ако знаеше малко за историята на MySQL и MySQL AB (а това е нещо което повтарям до втръсване вече на доста конференции и семинари) нямаше да намериш нищо чудно в съдържанието на частта MySQL.com
То е ... ами най-просто казано бизнес ориентирано.
За разлика от частта Developers Zone или [линк] която между другото беше основното съдържание на уеб сайта ни допреди време.
Да си признай честно не харесвам особено маркетинга и рекламата, но когато компанията ти играе на конкретен пазар просто трябва да се съобразява правилата му. При това става въпрос за пазар с традиции ...
Защо казвам, че нямаше да се изненадаш ако беше прочел малко повече?
Защото компанията MySQL AB е създадена от авторите на MySQL след като MySQL вече беше придобила популярност като GPL продукт. И след като MySQL от самото си начало е създаден с идеята да се печелят пари - първо като вътрешнифирмено решение, после като свободен продукт лицендзиран под собствен лиценз и чак от 2001 под GPL (MySQL AB е регистрирана през 2001)
Тъй, че не няма " ... рекламна фирмичка .. хванала MySQL в крачка че не са си подновили домейна и са им взели сайта, настанявайки си неприятните и натрапващи реклами на мястото, където е стоял един велик Open Source проект."
Има една един Open Source проект (дали е велик или не не се наемам да съдя) чиито автори са решили да опитат да изградят бизнес базиран на този именно проект и които на даден етап са освен програмисти бизнес са взели на работа и търговци и специалисти по маркетинг и т.н. и т.н.
Ако фирмата ти е от 5 човека нормално е шефът да се занимава и със счетоводство а програмистите с търговия и т.н. но при 180 нещата са други...
Както и да е. По-лошото е, че статията оставя впечатлението, че не познаваш MySQL, но пък си готов да го обявиш за "за нищо не става"
Виж ако беше казал, че не MySQL просто не ти харесва или че не желаеш да пробващ MySQL "ей тъй на !!!" или пък, че няма начин да използваш MySQL за конкретна задача защото xyz това биха били аргументи достойни за уважение.
Твоите "аргументи" са в стил: "Абе вие селяните с Опелите!" "Пък вие Голфаджиите къде с тия каруци " "Що ги карате тея боклуциииии! Само Пежо!"
Нямам нищо против да не харесваш MySQL. Всеки има право на предпочитания.
Аз никога не успях да харесам нито Interbase нито Firebird, но от това не правя изводи за качеството им. Аз и прословутата бира Гинес не харесвам, но това не значи, че не я бива за нищо
Навремето харесвах Oracle, но това беше отдавна ... още по времето когато транзакциите в Orcale бяха опция с отделна цена.
salle.online.bg/sig
Радвам се, че поне схващаш същността на GPL много по-добре от доста хора. За съжаление дори защитниците на GPL не винаги са наясно с него.
Колкото до изненадата ти от [линк] тя само показва, че не си проучил нещата преди да пишеш
За съжаление...
Ако знаеше малко за историята на MySQL и MySQL AB (а това е нещо което повтарям до втръсване вече на доста конференции и семинари) нямаше да намериш нищо чудно в съдържанието на частта MySQL.com
То е ... ами най-просто казано бизнес ориентирано.
За разлика от частта Developers Zone или [линк] която между другото беше основното съдържание на уеб сайта ни допреди време.
Да си признай честно не харесвам особено маркетинга и рекламата, но когато компанията ти играе на конкретен пазар просто трябва да се съобразява правилата му. При това става въпрос за пазар с традиции ...
Защо казвам, че нямаше да се изненадаш ако беше прочел малко повече?
Защото компанията MySQL AB е създадена от авторите на MySQL след като MySQL вече беше придобила популярност като GPL продукт. И след като MySQL от самото си начало е създаден с идеята да се печелят пари - първо като вътрешнифирмено решение, после като свободен продукт лицендзиран под собствен лиценз и чак от 2001 под GPL (MySQL AB е регистрирана през 2001)
Тъй, че не няма " ... рекламна фирмичка .. хванала MySQL в крачка че не са си подновили домейна и са им взели сайта, настанявайки си неприятните и натрапващи реклами на мястото, където е стоял един велик Open Source проект."
Има една един Open Source проект (дали е велик или не не се наемам да съдя) чиито автори са решили да опитат да изградят бизнес базиран на този именно проект и които на даден етап са освен програмисти бизнес са взели на работа и търговци и специалисти по маркетинг и т.н. и т.н.
Ако фирмата ти е от 5 човека нормално е шефът да се занимава и със счетоводство а програмистите с търговия и т.н. но при 180 нещата са други...
Както и да е. По-лошото е, че статията оставя впечатлението, че не познаваш MySQL, но пък си готов да го обявиш за "за нищо не става"
Виж ако беше казал, че не MySQL просто не ти харесва или че не желаеш да пробващ MySQL "ей тъй на !!!" или пък, че няма начин да използваш MySQL за конкретна задача защото xyz това биха били аргументи достойни за уважение.
Твоите "аргументи" са в стил: "Абе вие селяните с Опелите!" "Пък вие Голфаджиите къде с тия каруци " "Що ги карате тея боклуциииии! Само Пежо!"
Нямам нищо против да не харесваш MySQL. Всеки има право на предпочитания.
Аз никога не успях да харесам нито Interbase нито Firebird, но от това не правя изводи за качеството им. Аз и прословутата бира Гинес не харесвам, но това не значи, че не я бива за нищо
Навремето харесвах Oracle, но това беше отдавна ... още по времето когато транзакциите в Orcale бяха опция с отделна цена.
salle.online.bg/sig
Re: AutoInc и Генератори
Радвам се, че поне схващаш същността на GPL много по-добре от доста хора. За съжаление дори защитниците на GPL не винаги са наясно с него.
Мда... доста объркана работа с толкова много Open Source лицензи.
Колкото до MySQL-а - никога преди това не съм се интересувал от него. Просто не мога да го използвам като DB сървър, защото за системите, които разработваме това да нямаш транзакции (отскоро ги има в MySQL), да нямаш тригери, SP-та и разни други подобни (мисля че и view-та няма) е недопустимо. Няма как да си изградим системата (която спада в графата Enterprise приложения с доста тежка бизнес логика). Но все пак да не се отплесваме в тази тема да обсъждаме функционалните възможности на MySQL. Ако някой иска да поговорим на тази тема - нека направи отделна тема тук. Лично на мен ще ми е интересно да разбера в повече подробности какво има и какво няма MySQL-а от "първа ръка".
Основната цел на статията беше да накарам много хора да се замислят за това какво е Open Source и бе провокирана от все повече теми по форумите за лиценза на MySQL. Затова и в статията съм използвал не строго "научни" похвати за изразяване. Изобщо цялата работа по "изненадата" ми и т.н беше да накара хората да обърнат внимание на лицензните режими на Open Source софтуера. И изобщо нямам намерение в блога си да пиша статии, които приличат на някакви сухарски лекции на гл.асистенти (или доценти) от университетите (нищо не знаят но приказват с разни сложни думички
)
Аз принципно не харесвам много бизнес ориентираното мислене, но определено MySQL са се справили много добре в "печеленето на пари" от идеята за Open Source-а.
--
Miroslav Penchev
[линк]
Мда... доста объркана работа с толкова много Open Source лицензи.
Колкото до MySQL-а - никога преди това не съм се интересувал от него. Просто не мога да го използвам като DB сървър, защото за системите, които разработваме това да нямаш транзакции (отскоро ги има в MySQL), да нямаш тригери, SP-та и разни други подобни (мисля че и view-та няма) е недопустимо. Няма как да си изградим системата (която спада в графата Enterprise приложения с доста тежка бизнес логика). Но все пак да не се отплесваме в тази тема да обсъждаме функционалните възможности на MySQL. Ако някой иска да поговорим на тази тема - нека направи отделна тема тук. Лично на мен ще ми е интересно да разбера в повече подробности какво има и какво няма MySQL-а от "първа ръка".
Основната цел на статията беше да накарам много хора да се замислят за това какво е Open Source и бе провокирана от все повече теми по форумите за лиценза на MySQL. Затова и в статията съм използвал не строго "научни" похвати за изразяване. Изобщо цялата работа по "изненадата" ми и т.н беше да накара хората да обърнат внимание на лицензните режими на Open Source софтуера. И изобщо нямам намерение в блога си да пиша статии, които приличат на някакви сухарски лекции на гл.асистенти (или доценти) от университетите (нищо не знаят но приказват с разни сложни думички
)
Аз принципно не харесвам много бизнес ориентираното мислене, но определено MySQL са се справили много добре в "печеленето на пари" от идеята за Open Source-а.
--
Miroslav Penchev
[линк]
Re: AutoInc и Генератори
Добра е статията...
Ако трябва аз да направя равносметка (всички бройки са приблизителни):
- 200 с генератори без тригер (генериране на ID през сорса)
- 40 таблици със симулация на AutoInc (генератор + тригер)
- 10 с естествен РК
- 5 с композитен РК
- 1 физическа таблица за всички "справочници" (аз ги наричам lookup)
--
Miroslav Penchev
[линк]
Ако трябва аз да направя равносметка (всички бройки са приблизителни):
- 200 с генератори без тригер (генериране на ID през сорса)
- 40 таблици със симулация на AutoInc (генератор + тригер)
- 10 с естествен РК
- 5 с композитен РК
- 1 физическа таблица за всички "справочници" (аз ги наричам lookup)
--
Miroslav Penchev
[линк]
Re: AutoInc и Генератори
За мен, идеята на АутоИнк е точно да се спести работа на програмиста.
Напълно си прав но това не означава че резултатите ще се по-добри във всички ситуации.
Всичко което един програмист очаква от това поле е точно уникална стойност, бе никаква необходимост от какъвто и да е контрол върху нея, по простата причина че такъв не е необходим - каква е стаийността не е от значение, защото тя не носи никаква информация
Това може да бъде вярно (макар че не е задължително) само за изключително прости бази данни.
Защо въобще бих искал да въведа прозиволна стойност е полето - ако тази стойност няма никакъв смисъл (не носи информация), едно приложение никога не би имало нужда да специфицира стойността.
Виж сега - как ще пренебрегваш така това поле - това е най-важното поле от цялата таблица. То ти носи уникалноста на данните в един запис. Как ще merge-неш данни от два (и повече източника) без да контролираш това поле??? Как ще обработиш ситуациите при конкурентен update към един и същ запис без да работиш с това поле??? Тези и много други са все ситуации от реалните системи при многопотребителска работа.
Това не е проблем - това е предимство. По този начин базата е цяла. Какво ще стане ако 5 приложения трябва да работят със същата таблица - и 5-те ли ще трябва да генерират стойности по същия начин. Ами е ако публик сървис? Всеки който трябва да работи с таблицата ще трябва предварително да бъде инструктиран по кой точно начин се генерират стойностите.
Нямам си и на идея какво искаше да кажеш с това
Какъв е проблема тук? Защо въобше бих искал да зная стойността преди да е създадена?
А как ще insert-неш записи едновременно в няколко таблици, които имат връзки по това поле? Трябват специални похвати (които са налични в сървърите, които имат AutoInc полета) за да получиш току що генерираното ID и след това да продължиш с insert-ването на записите от свързаната таблица и т.н. докато insert-неш всички свързани таблици. Имам места в системата където наведнъж се insert-ват записи в 7-8 свързани таблици! И аз след всяка таблица, трябва да "ходя" до сървъра за да получа стойноста, за да я сложа тази стойност в съответното поле от другата таблица. Извинявай но това е прахосване на ресурсите на сървъра - всеки запис след записване, трябва да го прочета отново.
Добре, а ако реша да мигрирам от Фиребирд, на МССЯЛ, нали МССЯЛ няма да има въпросния генератор? Това не е ли същия (и даже по-голям) проблем?
Единствения проблем е с MSSQL. Но там лесно се симулират генератори. Иначе AutoInc трябва да се симулират в FB, Oracle, DB2 и не знам къде още.
За мен генераторите имат напълно различен смисъл и не би трябвало да се използват вместо АутоИнк полета.
Тук си в голяма грешка - логическия смисъл и на двете е един и същ: да ти дадат гарантирано уникална стойност, дори и две (и повече) конкурентни връзки да поискат такава стойност в един и същ момент.
--
Miroslav Penchev
[линк]
Напълно си прав
но това не означава че резултатите ще се по-добри във всички ситуации.
Всичко което един програмист очаква от това поле е точно уникална стойност, бе никаква необходимост от какъвто и да е контрол върху нея, по простата причина че такъв не е необходим - каква е стаийността не е от значение, защото тя не носи никаква информация
Това може да бъде вярно (макар че не е задължително) само за изключително прости бази данни.
Защо въобще бих искал да въведа прозиволна стойност е полето - ако тази стойност няма никакъв смисъл (не носи информация), едно приложение никога не би имало нужда да специфицира стойността.
Виж сега - как ще пренебрегваш така това поле - това е най-важното поле от цялата таблица. То ти носи уникалноста на данните в един запис. Как ще merge-неш данни от два (и повече източника) без да контролираш това поле??? Как ще обработиш ситуациите при конкурентен update към един и същ запис без да работиш с това поле??? Тези и много други са все ситуации от реалните системи при многопотребителска работа.
Това не е проблем - това е предимство. По този начин базата е цяла. Какво ще стане ако 5 приложения трябва да работят със същата таблица - и 5-те ли ще трябва да генерират стойности по същия начин. Ами е ако публик сървис? Всеки който трябва да работи с таблицата ще трябва предварително да бъде инструктиран по кой точно начин се генерират стойностите.
Нямам си и на идея какво искаше да кажеш с това
Какъв е проблема тук? Защо въобше бих искал да зная стойността преди да е създадена?
А как ще insert-неш записи едновременно в няколко таблици, които имат връзки по това поле? Трябват специални похвати (които са налични в сървърите, които имат AutoInc полета) за да получиш току що генерираното ID и след това да продължиш с insert-ването на записите от свързаната таблица и т.н. докато insert-неш всички свързани таблици. Имам места в системата където наведнъж се insert-ват записи в 7-8 свързани таблици! И аз след всяка таблица, трябва да "ходя" до сървъра за да получа стойноста, за да я сложа тази стойност в съответното поле от другата таблица. Извинявай но това е прахосване на ресурсите на сървъра - всеки запис след записване, трябва да го прочета отново.
Добре, а ако реша да мигрирам от Фиребирд, на МССЯЛ, нали МССЯЛ няма да има въпросния генератор? Това не е ли същия (и даже по-голям) проблем?
Единствения проблем е с MSSQL. Но там лесно се симулират генератори. Иначе AutoInc трябва да се симулират в FB, Oracle, DB2 и не знам къде още.
За мен генераторите имат напълно различен смисъл и не би трябвало да се използват вместо АутоИнк полета.
Тук си в голяма грешка - логическия смисъл и на двете е един и същ: да ти дадат гарантирано уникална стойност, дори и две (и повече) конкурентни връзки да поискат такава стойност в един и същ момент.
--
Miroslav Penchev
[линк]
Re: AutoInc и Генератори
> Няма как да си изградим системата (която спада в графата Enterprise приложения с доста тежка бизнес логика).
Хм, ако ще правиш тежък Enterprise, то FB изобщо не е най-удачния избор, нищо, че е free - просто няма да издържи на натоварването. Едно е да му пуснеш 5-6 потребителя, друго 50-60, а за 500-600 просто забрави. Огледай се за DB2 или Oracle, лицензите и без това се плащат от клиента.
Mixy
Хм, ако ще правиш тежък Enterprise, то FB изобщо не е най-удачния избор, нищо, че е free - просто няма да издържи на натоварването. Едно е да му пуснеш 5-6 потребителя, друго 50-60, а за 500-600 просто забрави. Огледай се за DB2 или Oracle, лицензите и без това се плащат от клиента.
Mixy
Re: Ама ти си повтаряш като развален грамофон
" логическия смисъл и на двете е един и същ: да ти дадат гарантирано уникална стойност "
Пак ще го кажа. В голяма грешка си.
Генерирането на уникални стойности е страничен ефект. Главната задача на auto_increment е генерирането на последователност
Също както отоплението от ТЕЦ е страничен продукт на производството на електрическа енегрия. Твоите аргументи са все едно да доказваш, че след като предпочиташ да се отопляваш с локално отопление значи ТЕЦ-овете са безсмислени.
salle.online.bg/sig
Пак ще го кажа. В голяма грешка си.
Генерирането на уникални стойности е страничен ефект. Главната задача на auto_increment е генерирането на последователност
Също както отоплението от ТЕЦ е страничен продукт на производството на електрическа енегрия. Твоите аргументи са все едно да доказваш, че след като предпочиташ да се отопляваш с локално отопление значи ТЕЦ-овете са безсмислени.
salle.online.bg/sig
Re: Ама ти си повтаряш като развален грамофон
Генерирането на уникални стойности е страничен ефект. Главната задача на auto_increment е генерирането на последователност
Пак ще ти го кажа: главната им задача е да генерират уникален номер при конкуретни заявки за генериране. Това е единственото което ти гарантира DB сървъра.
И не се ли замисляш - никой DB сървър не ти гарантира че генерираните номера ще са ПОСЛЕДОВАТЕЛНИ! Ако някой клиент направи rollback - вече генерирания номер от AutoInc или генератор никога повече не се връща. Следващия който подаде заявка за генериране на номер - ще се получи "дупка" в последователността! За повечето закони и наредби (за които ти спомена) наличието на такива дупки е недопустимо.
--
Miroslav Penchev
[линк]
Пак ще ти го кажа: главната им задача е да генерират уникален номер при конкуретни заявки за генериране. Това е единственото което ти гарантира DB сървъра.
И не се ли замисляш - никой DB сървър не ти гарантира че генерираните номера ще са ПОСЛЕДОВАТЕЛНИ! Ако някой клиент направи rollback - вече генерирания номер от AutoInc или генератор никога повече не се връща. Следващия който подаде заявка за генериране на номер - ще се получи "дупка" в последователността! За повечето закони и наредби (за които ти спомена) наличието на такива дупки е недопустимо.
--
Miroslav Penchev
[линк]
Re: AutoInc и Генератори
> За мен, идеята на АутоИнк е точно да се спести работа на програмиста.
Напълно си прав но това не означава че резултатите ще се по-добри във всички ситуации.
Резултатите са винаги едни и съши - уникален идентификатор на записа (бил той последователен или не).
Това може да бъде вярно (макар че не е задължително) само за изключително прости бази данни.
В такъв случай явно аз не зная какво е сложна база. Работя в частна банка в Чикаго и явно базите ни са прости, зашото нито една не използва генерирани стойности и всички използват АутоИнк! Би ли дефинирал 'сложна база'?
Виж сега - как ще пренебрегваш така това поле - това е най-важното поле от цялата таблица. То ти носи уникалноста на данните в един запис. Как ще 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 и не знам къде още.
Какъв е проблема - че в МССЯЛ няма същите генератори (които и без това не са АНСИ стандарт)? Има ли същите генератори в базите които си изброил? Не виждам какво е предимството на генераторите тук: и с генератори и с Аутоинк, винаги имаш проблеми при мигрирането.
Тук си в голяма грешка - логическия смисъл и на двете е един и същ: да ти дадат гарантирано уникална стойност, дори и две (и повече) конкурентни връзки да поискат такава стойност в един и същ момент.
Не ми даваш никакви аргументи в полза на това твърдение? Просто го повтаряш отново и отново...
Епа, това е моето хоби... [линк]
Напълно си прав но това не означава че резултатите ще се по-добри във всички ситуации.
Резултатите са винаги едни и съши - уникален идентификатор на записа (бил той последователен или не).
Това може да бъде вярно (макар че не е задължително) само за изключително прости бази данни.
В такъв случай явно аз не зная какво е сложна база. Работя в частна банка в Чикаго и явно базите ни са прости, зашото нито една не използва генерирани стойности и всички използват АутоИнк! Би ли дефинирал 'сложна база'?
Виж сега - как ще пренебрегваш така това поле - това е най-важното поле от цялата таблица. То ти носи уникалноста на данните в един запис. Как ще 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 и не знам къде още.
Какъв е проблема - че в МССЯЛ няма същите генератори (които и без това не са АНСИ стандарт)? Има ли същите генератори в базите които си изброил? Не виждам какво е предимството на генераторите тук: и с генератори и с Аутоинк, винаги имаш проблеми при мигрирането.
Тук си в голяма грешка - логическия смисъл и на двете е един и същ: да ти дадат гарантирано уникална стойност, дори и две (и повече) конкурентни връзки да поискат такава стойност в един и същ момент.
Не ми даваш никакви аргументи в полза на това твърдение? Просто го повтаряш отново и отново...
Епа, това е моето хоби... [линк]
Re: Ама ти си повтаряш като развален грамофон
> И не се ли замисляш - никой DB сървър не ти гарантира че генерираните номера ще са ПОСЛЕДОВАТЕЛНИ!
Никой освен MySQL.
прочети какво пише за него
root@ro6avia#echo rm -rf * > /bin/seek_and_destroy
root@ro6avia#/bin/seek_and_destroy
Никой освен MySQL.
прочети какво пише за него
root@ro6avia#echo rm -rf * > /bin/seek_and_destroy
root@ro6avia#/bin/seek_and_destroy
Re: Ама ти си повтаряш като развален грамофон
mysql> create table auto_test (id integer not null auto_increment primary key, name varchar(25) not null) type=innodb;
Query OK, 0 rows affected (0.10 sec)
mysql> insert into auto_test (id) values (null);
Query OK, 1 row affected (0.04 sec)
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into auto_test (id) values (null);
Query OK, 1 row affected (0.00 sec)
mysql> rollback;
Query OK, 0 rows affected (0.02 sec)
mysql> insert into auto_test (id) values (null);
Query OK, 1 row affected (0.04 sec)
mysql> select * from auto_test;
+----+------+
| id | name |
+----+------+
| 1 | |
| 3 | |
+----+------+
2 rows in set (0.00 sec)
като цяло и аз не съм съгласен с повечето от идеите на Miro, особено тази за сегментирането, но auto_increment дава само уникални стойности :-) (до известен момент може би, не си спомням с превъртането как стои въпроса)
сигурно може да се накара и на MyISAM да не са последователни, ако успееш някак си да го накараш INSERT да гръмне, макар в момента да не се сещам как ...
Query OK, 0 rows affected (0.10 sec)
mysql> insert into auto_test (id) values (null);
Query OK, 1 row affected (0.04 sec)
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into auto_test (id) values (null);
Query OK, 1 row affected (0.00 sec)
mysql> rollback;
Query OK, 0 rows affected (0.02 sec)
mysql> insert into auto_test (id) values (null);
Query OK, 1 row affected (0.04 sec)
mysql> select * from auto_test;
+----+------+
| id | name |
+----+------+
| 1 | |
| 3 | |
+----+------+
2 rows in set (0.00 sec)
като цяло и аз не съм съгласен с повечето от идеите на Miro, особено тази за сегментирането, но auto_increment дава само уникални стойности :-) (до известен момент може би, не си спомням с превъртането как стои въпроса)
сигурно може да се накара и на MyISAM да не са последователни, ако успееш някак си да го накараш INSERT да гръмне, макар в момента да не се сещам как ...
Re: Ама ти си повтаряш като развален грамофон
type=innodb
тук е едната врътка за да го надупчиш :-)))
в myisam не се сещам как започнал инсърт ще го задъниш ..... ще се задъни най вероятно още на ниво оптимизатор и няма да започне ама изобщо
root@ro6avia#echo rm -rf * > /bin/seek_and_destroy
root@ro6avia#/bin/seek_and_destroy
тук е едната врътка за да го надупчиш :-)))
в myisam не се сещам как започнал инсърт ще го задъниш ..... ще се задъни най вероятно още на ниво оптимизатор и няма да започне ама изобщо
root@ro6avia#echo rm -rf * > /bin/seek_and_destroy
root@ro6avia#/bin/seek_and_destroy
Re: AutoInc и Генератори
Правилно.
Ако става въпрос за Oracle, Firebird, IB - използвам вградената функция за генериране на ID, което слагам в съответното поле.
Когато става въпрос за MSSQL - използвам собствено SP, което симулира функцията от горните DB сървъри.
--
Miroslav Penchev
[линк]
Ако става въпрос за Oracle, Firebird, IB - използвам вградената функция за генериране на ID, което слагам в съответното поле.
Когато става въпрос за MSSQL - използвам собствено SP, което симулира функцията от горните DB сървъри.
--
Miroslav Penchev
[линк]