Форум: "Прочее";
Текущий архив: 2006.05.21;
Скачать: [xml.tar.bz2];
Вниз
Первичный ключ Найти похожие ветки
← →
Mozart © (2006-04-15 20:54) [0]Вот такой вопрос - есть поля - "ФИО" "Дата рождения" "Телефон", так по какому первичный ключ заводить? Если говорит прямо - только сейчас решил заняться БД, как говориться "конкретно"...
← →
Kerk © (2006-04-15 20:59) [1]По еще одному, которое autoincrement
← →
Sam Stone © (2006-04-15 20:59) [2]Создать еще одное поле типа number/integer/еще-какой-циферный и сделать его ключом. Потому что ни одно из этих полей не обеспечит уникальность записи.
← →
Mozart © (2006-04-15 21:05) [3]Вы имеете ввиду, что то вроде id?
← →
Kerk © (2006-04-15 21:06) [4]Да
← →
Mozart © (2006-04-15 21:10) [5]Kerk © (15.04.06 21:06) [4]
Да
Ok, тогда смоделируем ситуацию, когда речь идет о двух филиалах одной фирмы, БД, которых не связаны и самостоятельны, и задача (например) - совместить БД, что тогда?
← →
Kerk © (2006-04-15 21:12) [6]Я бы составлял ключ из двух частей: id-филиала и уникальное значение сиквенкса.
← →
Mozart © (2006-04-15 21:14) [7]Т.е. ты хочешь сказать, что id обязательный пункт в любой БД? А не получается громоздкая модель?
← →
Marser © (2006-04-15 21:14) [8]> [1] Kerk © (15.04.06 20:59)
> По еще одному, которое autoincrement
Кстати, когда-то давно, когда я в БД ещё практически ничего не смыслил, была тут такая точка зрения(причём, у одного из нынешних мастеров), что автинкререментное поле делать ключевым нехорошо. Я так и не понял, почему...
← →
Kerk © (2006-04-15 21:17) [9]Marser © (15.04.06 21:14) [8]
Оптимально имхо использовать что-то типа [6]. Почему сам по себе автоинкремент плох в общем случае - хз.
Mozart © (15.04.06 21:14) [7]
А не получается громоздкая модель?
С чего бы?
← →
Sam Stone © (2006-04-15 21:22) [10]>Ok, тогда смоделируем ситуацию, когда речь идет о двух филиалах одной
> фирмы, БД, которых не связаны и самостоятельны, и задача (например) -
>совместить БД, что тогда?
В смысле чтобы косяка из-за одинаковых id записей не было? Сделать апдейт каскадом на совпадающие идентификаторы и после слить ;)
← →
Mozart © (2006-04-15 21:26) [11]to Sam Stone © (15.04.06 21:22) [10]
ну я ОЧЕНЬ мало смыслю в БД, но, по - моему - так некорректно...:)
to Kerk © (15.04.06 21:17) [9]
насчет громоздкости - так ведь два новых поля...
← →
Desdechado © (2006-04-15 21:28) [12]> по какому первичный ключ заводить
по таким фундаментальным вопросам, особенно при "решил заняться БД, как говориться конкретно", надо книжки читать, а уж при непонятностях там спрашивать в форуме
каждый случай индивидуален и универсальных советов тут не бывает
← →
Sam Stone © (2006-04-15 21:30) [13]2Mozart
Некорреткности не виду ) разве что коряво ) При каскадном обновлении все внешние ключи поменяются автоматом и юзеры даже не заметят разницы )
А вообще в каждом конкретном случае отдельно надо думать.
← →
Kerk © (2006-04-15 21:31) [14]Mozart © (15.04.06 21:26) [11]
насчет громоздкости - так ведь два новых поля...
Почему два? Одно.
← →
Mozart © (2006-04-15 21:32) [15]Ребята - яж не про конкретный проект спрашиваю :), просто ставлю перед собой задачи и пытаюсь их решить, правда с Вашей помощью :)
← →
SergP. (2006-04-15 22:06) [16]
> насчет громоздкости - так ведь два новых поля...
А заводить первичный ключ по ФИО - не громоздко?
← →
Lamer@fools.ua © (2006-04-15 22:11) [17]По сабджу:
http://www.informix.com.ua/articles/key/key.htm
← →
Mozart © (2006-04-15 22:16) [18]to SergP. (15.04.06 22:06) [16]
а я и спрашивал - по какому корректно :) из существующих, мне говорили, что id как раз некорректно...Ф:(
← →
xayam © (2006-04-15 22:17) [19]
> Mozart ©
База данных для того и делают чтобы обеспечить быстрый поиск в большом объеме информации, при этом каждый первичный ключ индексируется.
← →
sniknik © (2006-04-15 22:18) [20]> насчет громоздкости - так ведь два новых поля...
id-филиала + id-записи
и то и то число, поиски, фильтры, индексы, связки и т.д. по числовым полям на порядки быстрее чем по строковым... учитывай что еще и апдейты записей с клиента на ключь завязаны (запрос на обновление по нему составляется... в основном).
т.е. имея ключь даже по 2 числовым полям будеш в выигрыше по сравнению с по одному текстовому.
(и даже не по двум а больше, но это уже перебор в данном случае)
в общем это не громоздкость это наоборот облегчением будет...
← →
xayam © (2006-04-15 22:19) [21]
> > Mozart ©
и потом разберись что такое внешний ключ, ты этого видимо не знаешь, раз спрашиваешь зачем первичный
← →
Marser © (2006-04-15 22:21) [22]Кстати, а ФИО одним полем это однозначный моветон, такая БД даже на первую нормальную форму не тянет...
← →
Lamer@fools.ua © (2006-04-15 22:23) [23]>Кстати, а ФИО одним полем это однозначный моветон, такая БД даже на первую нормальную форму не тянет...
Смотря, как это поле "ФИО" потом будет использоваться.
← →
Mozart © (2006-04-15 22:24) [24]2 xayam © (15.04.06 22:17) [19]
> Mozart ©
База данных для того и делают чтобы обеспечить быстрый поиск в большом объеме информации, при этом каждый первичный ключ индексируется.
"Прошу пардона" (с) теорию знаю, я ведь про практику спрашивал...
to sniknik © (15.04.06 22:18) [20]
да я тут просто думаю - если филиалов конторы не 2 и даже не 5, притом, что создавались они задолго до объединения - структуры разные...тогда как?
← →
Marser © (2006-04-15 22:27) [25]> [23] Lamer@fools.ua © (15.04.06 22:23)
> >Кстати, а ФИО одним полем это однозначный моветон, такая
> БД даже на первую нормальную форму не тянет...
>
> Смотря, как это поле "ФИО" потом будет использоваться.
В общем, да. Если это что-то дополнительное и опциональное, то необязательно. А вот по сабжу выходит, что база всё-таки по людям.
← →
xayam © (2006-04-15 22:28) [26]
> "Прошу пардона" (с) теорию знаю, я ведь про практику спрашивал.
> ..
а это что в разных измерениях находится?
← →
Mozart © (2006-04-15 22:29) [27]to Marser © (15.04.06 22:27) [25]
ну, допустим, по сотрудникам - а если бы было поле ИНН, по нему можно сделать ключ?
← →
Marser © (2006-04-15 22:31) [28]> [27] Mozart © (15.04.06 22:29)
> to Marser © (15.04.06 22:27) [25]
> ну, допустим, по сотрудникам - а если бы было поле ИНН,
> по нему можно сделать ключ?
Я извиняюсь за неброзавнность, но что такое ИНН?
← →
xayam © (2006-04-15 22:31) [29]
> Mozart © (15.04.06 22:29) [27]
теоретически можно, а практически я бы не делал
← →
xayam © (2006-04-15 22:34) [30]Тогда у тебя получится что база данных будет зависеть от внешней среды (которая называется жизнью), а оно тебе надо?
← →
sniknik © (2006-04-15 22:35) [31]> если филиалов конторы не 2 и даже не 5
ну значит в "id-филиала" у тебя будут значения не от одного до пяти а больше... до тысячи например. делов то.
> структуры разные...тогда как?
приводить к одной, иначе смысла в системе мало. либо в центре под каждую делать конвертор для слития данных... (стоит начать и уже не остановишся... поверь опыту, потом хрен начальству поясниш, что проще заново новую написать, чем пару конверторов под системы которые на местах будут "ляпать" кто во что горазд...)
← →
Mozart © (2006-04-15 22:36) [32]to Marser © (15.04.06 22:31) [28]
:))) ну индивидуальный номер налогоплательщика - ты, наверное, еще не работаешь, поэтому не знаешь :), но у всех, кто официально устроен есть такая бумажка...
to xayam ©
насчет теории и практики - это уже извечный вопрос - "могут ли научить чему - либу новому в ВУЗ`е"
А почему не делал бы?
← →
Внук © (2006-04-15 22:37) [33]Однозначно придерживаюсь позиции, что первичный ключ естественным быть не должен. Поэтому всякие ИНН, а тем более ФИО в качестве первичного ключа - маст дай.
← →
Mozart © (2006-04-15 22:39) [34]Внук © (15.04.06 22:37) [33]
так все - таки id ?
← →
xayam © (2006-04-15 22:39) [35]
> А почему не делал бы?
[30]
> "могут ли научить чему - либу новому в ВУЗ`е"
Вузы ничему не учат, это только от тебя зависет
← →
Внук © (2006-04-15 22:43) [36]>>Mozart © (15.04.06 22:39) [34]
Да. Числовой идентификатор записи.
← →
Marser © (2006-04-15 22:44) [37]> [32] Mozart © (15.04.06 22:36)
> to Marser © (15.04.06 22:31) [28]
> :))) ну индивидуальный номер налогоплательщика - ты, наверное,
> еще не работаешь, поэтому не знаешь :), но у всех, кто
> официально устроен есть такая бумажка...
Нет, я таки работаю, причем уже три года, но есть два но - слава Богу, не в бухгалтерии и даже не рядом, а во во-вторых - в Украине это называется "Персональний ідентифікаційний номер фізичної особи - платника податків".
Так вот, так, как он формируется у нас - ИМХО, можно делать ключевым. Только ногами не бейте :-)
← →
Внук © (2006-04-15 22:47) [38]>>Marser © (15.04.06 22:44) [37]
Да можно, конечно, если имеется в виду его уникальность для каждого человека. Только мне часто встречались задачи, когда уникальности такой не хватает. То есть нужна не уникальность характеристики объекта, а ункальность самой записи. Поэтому взял за правило - проблем меньше.
← →
xayam © (2006-04-15 22:48) [39]
> Только ногами не бейте :-)
надо бы)) но сначала хотелось узнать как это он у Вас по-особенному формируется
← →
Mozart © (2006-04-15 22:48) [40]to Marser © (15.04.06 22:44) [37]
"Персональний ідентифікаційний номер фізичної особи - платника податків".
прикольно звучит :)
to Внук © (15.04.06 22:43) [36]
а по ИНН нельзя? или некорректно?
← →
Kerk © (2006-04-15 22:51) [41]Mozart © (15.04.06 22:48) [40]
а по ИНН нельзя?
Сказали же - зависит от задачи, но я бы в любом случае не стал.
← →
Внук © (2006-04-15 22:51) [42]>>Mozart © (15.04.06 22:48) [40]
В твоей задаче, вероятно, можно. Скажем, при учете юр. лиц это не пройдет, поскольку головное предприятие и филиал имеют одинаковый ИНН. Да и не нужно информационные поля нагружать дополнительными смыслами, чесслово.
← →
Mozart © (2006-04-15 22:57) [43]ну у меня знакомый работает в пенсионном фонде, так там id - карается руководством...
← →
SergP © (2006-04-15 22:58) [44]
> Mozart © (15.04.06 20:54)
> Вот такой вопрос - есть поля - "ФИО" "Дата рождения" "Телефон",
> так по какому первичный ключ заводить? Если говорит прямо
> - только сейчас решил заняться БД, как говориться "конкретно".
> ..
По имеющимся полям ПК делать нехорошо по понятным причинам, дополнительные поля тебе не нравятся...
Может тебе вообще не нужен ПК?
← →
Kerk © (2006-04-15 23:00) [45]Mozart © (15.04.06 22:57) [43]
ну у меня знакомый работает в пенсионном фонде, так там id - карается руководством...
Так прям и карается? :D
← →
sniknik © (2006-04-15 23:01) [46]> а по ИНН нельзя? или некорректно?
представь у тебя уже есть подобная база... работает, и тут выясняется то комуто вбили неправильный INN (сам то он уникальный не вопрос, но квиточки то могли спутать?)
теперь тебе надо исправить, и не просто так, а старые записи оставить (с пометкой для истории "ошибочно, оператор Иванов - гнида подзаборная" ;о))), правильные естественно переввести. как ты это сделаеш, если у тебя уникальность на уровне сущьности? сдублировать запись не даст. а вот с уникальностью на уровне записи, да без проблемм.
и даже если есть вторичный уникальный индекс по INN то не проблема, можно изменить, добавить левый символ какойто для ошибочных записей к самому INN не боясь, что во всех документах связки "порвутся".
← →
Mozart © (2006-04-15 23:01) [47]SergP © (15.04.06 22:58) [44]
:) да причем тут "не нравяться" - понять хочу - нужны или нет, а если нужны то какие ..:)
← →
Marser © (2006-04-15 23:02) [48]> [40] Mozart © (15.04.06 22:48)
> to Marser © (15.04.06 22:44) [37]
> "Персональний ідентифікаційний номер фізичної особи - платника
> податків".
>
> прикольно звучит :)
А так:
пэрсональный идэнтыфыкацийный номэр физычнойи особы - платныка податкив
Потому что звучит это именно так, а означает "персональцый идентификационный номер физического лица - налогоплательщика".
> но сначала хотелось узнать как это он у Вас по-особенному
> формируется
Точно не помню, но алгоритм ведет к тому, что можно расшифровать дату рождения и пол и исключены совпадения.
← →
xayam © (2006-04-15 23:07) [49]
> Marser © (15.04.06 23:02) [48]
[30] [46]
← →
Mozart © (2006-04-15 23:07) [50]to Marser © (15.04.06 23:02) [48]
дык я ж не с сарказмом, просто прикольно :)
кстати - были такие слухи - в советских паспортах (в номере и серии) была, ко всему прочему, и национальность...и прочие интимные вещи...
← →
SergP © (2006-04-15 23:10) [51]
> Точно не помню, но алгоритм ведет к тому, что можно расшифровать
> дату рождения и пол и исключены совпадения.
На Украине ИНН представляет собой десятизначное число. Первые 5 цифр однозначно определяют дату рождения, предпоследняя - пол. последняя цифра - контрольная. (Российские ИНН имеют похожие принципы). Это все можно проверять при вводе, чтобы никакая
"оператор Иванов - гнида подзаборная" не ввела что-то неправильное.
Правда есть на Украине одна интерестная вещь: алгоритм формирования ИНН знают все, но он почему-то считается чем-то типа государственной тайны. Т.е. применять в ПО его нельзя...
← →
Marser © (2006-04-15 23:11) [52]> [49] xayam © (15.04.06 23:07)
>
> > Marser © (15.04.06 23:02) [48]
>
> [30] [46]
В общем, правильно. И с прозвучавшей мыслью о том, что ПК желательно делать по неинформационному полю, я тоже согласен.
← →
Игорь Шевченко © (2006-04-15 23:11) [53]Внук © (15.04.06 22:37) [33]
> Однозначно придерживаюсь позиции, что первичный ключ естественным
> быть не должен. Поэтому всякие ИНН, а тем более ФИО в качестве
> первичного ключа - маст дай.
>
С пуристами дискутировать - себе дороже :)
Вот тебе примерчик - есть кодировка стран (и прочей географии) по ISO. Двухбуквенный код, например UA для Украины. Будем ID вводить или обойдемся кодом ISO ?
← →
SergP © (2006-04-15 23:24) [54]ИМХО использование ИНН для ПК вполне логично...Правда смотря где...
Например у нас (где ИНН не есть уникальным), для однозначной идентификации налогоплательщика используется некий GUID, вот по нему и делается первичный и внешние ключи.
← →
Marser © (2006-04-15 23:26) [55]> [54] SergP © (15.04.06 23:24)
> ИМХО использование ИНН для ПК вполне логично...Правда смотря
> где...
> Например у нас (где ИНН не есть уникальным), для однозначной
> идентификации налогоплательщика используется некий GUID,
> вот по нему и делается первичный и внешние ключи.
Стоп, так под ИНН понимается не то, что я написал?
← →
Игорь Шевченко © (2006-04-15 23:30) [56]SergP © (15.04.06 23:24) [54]
> Например у нас (где ИНН не есть уникальным), для однозначной
> идентификации налогоплательщика используется некий GUID
Давно пора людям вместо имен GUID давать. Для однозначной идентификации. А вообще странно - вроде как налогоплательщик уникально идентифицируется именно ИНН, на то он и индивидуальный номер, вроде бы.
← →
SergP © (2006-04-15 23:45) [57]
> Стоп, так под ИНН понимается не то, что я написал?
Именно то... Просто у нас есть некоторые свои ньюансы...
Хотя на самом деле вместо "где ИНН не есть уникальным" правильнее было бы написать "где ИНН или код ЕДРПОУ не есть уникальным". Но это дела не меняет, так как ИНН и коды ЕДРПОУ не пересекаются.
← →
Johnmen © (2006-04-16 00:40) [58]Всем дискутирующим (если интересуются) и в первую очередь автору,
читать про суррогатные и натуральные ключи.
http://www.ibase.ru/devinfo/NaturalKeysVersusAtrificialKeysByTentser.html
и здесь докучи
http://www.ibase.ru/devinfo/oop_rdbms.htm
← →
Marser © (2006-04-16 00:46) [59]> http://www.ibase.ru/devinfo/NaturalKeysVersusAtrificialKeysByTentser.html
Весьма убедительно, на мой взгляд.
← →
Джо © (2006-04-16 01:00) [60]> [59] Marser © (16.04.06 00:46)
>
> Весьма убедительно, на мой взгляд.
Еще бы не убедительно — второй раз уже эту статью рекоммендуют в ветке ;)
([17])
← →
Marser © (2006-04-16 01:05) [61]> [60] Джо © (16.04.06 01:00)
> > [59] Marser © (16.04.06 00:46)
> >
> > Весьма убедительно, на мой взгляд.
>
> Еще бы не убедительно — второй раз уже эту статью рекоммендуют
> в ветке ;)
> ([17])
Гы, характерно, что у Самого Тенцера uin ICQ младше моего :-)
← →
Внук © (2006-04-16 10:56) [62]>>Игорь Шевченко © (15.04.06 23:11) [53]
Есть такой справочник. Будем вводить. По причине номер раз - для однообразия правил формирования таблиц, по причине номер два - для половины вводимой информации операторы не знают этих кодов, и знать не хотят.
← →
isasa © (2006-04-16 11:43) [63]Внук © (16.04.06 10:56) [62]
>>Игорь Шевченко © (15.04.06 23:11) [53]
+ если захотим зацепить механизм репликации, то тогда нам уже точно расскажут какой ключ должен быть :)
← →
Anatoly Podgoretsky © (2006-04-16 13:56) [64]SergP © (15.04.06 23:10) [51]
На Украине ИНН представляет собой десятизначное число. Первые 5 цифр однозначно определяют дату рождения, предпоследняя - пол. последняя цифра - контрольная.
По пяти символам невозможно однозначно определить дату рождения, даже по шести нельзя, если смотреть в перспективе, что номера должны существовать вечно, а не 50 лет.
У нас используются 11 значные номера - пол, ГГММДД, ####
Что дает 7 300 000 номеров на каждый год, но думаю лет через 50 перейдут на 13 значные, когда поймут, что человек может жить свыше ста лет, не говоря уж об государстве.
← →
vuk © (2006-04-16 18:32) [65]to Игорь Шевченко © (15.04.06 23:30) [56]:
>вроде как налогоплательщик уникально идентифицируется именно ИНН, на
>то он и индивидуальный номер, вроде бы
Оно конечно да, но ведь этот ключ в базе потом наверняка еще и как внешний будет использоваться. А про то, что ИНН могут неверно вбить уже говорили. В конце концов можно посмотреть на проблему иначе. Уникальна конкретная личность, а ИНН - некий атрибут который ей государство присвоило и не дело нашей БД, что оно там присвоило и как сгенерило.
В примере со странами история другая, но тут уж все зависит от конкретной БД, куда это все прикручиваться как справочник будет. Возможно удобнее будет сделать дополнительное ключевое поле для однородности методики идентификации записей по БД в целом.
← →
Mozart © (2006-04-16 19:15) [66]vuk © (16.04.06 18:32) [65]
ИНН - некий атрибут который ей государство присвоило и не дело нашей БД, что оно там присвоило и как сгенерило.
а ПК разве не совокупность атрибутов?
← →
vuk © (2006-04-16 19:43) [67]to Mozart © (16.04.06 19:15) [66]:
>а ПК разве не совокупность атрибутов?
Любой ключ - это совокупность атрибутов, одного или более. Другое дело, насколько удобно использовать составные ключи в качестве внешних. Ведь обычно ключ на то и нужен, чтобы потом по нему ссылки делать. Если в БД ПК составной, то чтобы потом сослаться на запись из другой таблицы, придется добавить в эту таблицу все поля, входящие в ПК. Ну и, соответственно, о выборках тоже надо думать.
Если же нужна просто уникальность(не для ссылок), то обычно используются уникальные индексы.
И еще. Для учета людей естественные ключи не подходят. Приходится генерить искусственные. ИНН - это тоже искусственный ключ, только от другой БД. Тут уж личное дело каждого - использовать ключи, пришедшие из другой БД или генерировать свои.
← →
Mozart © (2006-04-16 19:53) [68]естественный ключ - это ФИО? Дата рождения?
← →
Leonid Troyanovsky © (2006-04-16 19:55) [69]
> Mozart © (16.04.06 19:53) [68]
> естественный ключ - это ФИО? Дата рождения?
Сказали ж - не может быть для человека естественных ключей.
Даже ДНК код не может, бо клонируют.
--
Regards, LVT.
← →
Mozart © (2006-04-16 19:56) [70]Leonid Troyanovsky © (16.04.06 19:55) [69]
Вот теперь понял - спасибо :)
← →
SergP. (2006-04-16 19:57) [71]
> Anatoly Podgoretsky © (16.04.06 13:56) [64]
> SergP © (15.04.06 23:10) [51]
> На Украине ИНН представляет собой десятизначное число. Первые
> 5 цифр однозначно определяют дату рождения, предпоследняя
> - пол. последняя цифра - контрольная.
>
> По пяти символам невозможно однозначно определить дату рождения,
> даже по шести нельзя, если смотреть в перспективе, что
> номера должны существовать вечно, а не 50 лет.
Имелось ввиду конечно в определеном периоде... около 270 лет
А если предположить что жизнь на земле будет вечной, то и любого фиксированного количества цифр не хватит.
← →
Leonid Troyanovsky © (2006-04-16 20:02) [72]
> SergP. (16.04.06 19:57) [71]
> А если предположить что жизнь на земле будет вечной, то
> и любого фиксированного количества цифр не хватит.
Почему ж не хватит? Тогда будет ограниченное число людей.
--
Regards, LVT.
← →
Anatoly Podgoretsky © (2006-04-16 20:17) [73]SergP. (16.04.06 19:57) [71]
На ближайшие 8000 лет можно не беспокоиться.
← →
SergP © (2006-04-16 20:27) [74]
> Почему ж не хватит? Тогда будет ограниченное число людей.
Но ведь ИНН который был присвоен человеку, который уже умер не дается снова новому человеку. По крайней мере пока так....
← →
Карелин Артем © (2006-04-16 20:41) [75]Насчет ФИО: у нас в группе в колледже были двое с одинаковыми ФИО, да еще и даты рождения почти совпадали.
← →
Leonid Troyanovsky © (2006-04-16 21:16) [76]
> SergP © (16.04.06 20:27) [74]
> > Почему ж не хватит? Тогда будет ограниченное число людей.
> Но ведь ИНН который был присвоен человеку, который уже умер
> не дается снова новому человеку. По крайней мере пока так.
Дык, если перположить, что люди будут жить вечно, то число их будет ограничено, а это время наступит через конечное число лет.
Сл-но, общее число (живших и живущих людей) будет ограничено.
Конечно, эти рассуждения не касаются Царствия Божия на земле,
бо в нем нет никаких ИНН.
--
Regards, LVT.
← →
SergP © (2006-04-16 21:49) [77]
> Конечно, эти рассуждения не касаются Царствия Божия на земле,
>
> бо в нем нет никаких ИНН.
Интерестно, как тогда будут идентифицироваться люди в Царствии Божием?
← →
Джо © (2006-04-16 22:05) [78]> [77] SergP © (16.04.06 21:49)
> Интерестно, как тогда будут идентифицироваться люди в Царствии
> Божием?
В соответствии с первоисточником: "Каждого — по делам его" :)
← →
Marser © (2006-04-16 22:19) [79]Просто ИНН это далеко не та технология, которая делается на века. Потому что соприкасается с двумя переменчивыми сферами - ИТ и законодательной.
← →
Игорь Шевченко © (2006-04-17 11:05) [80]Внук © (16.04.06 10:56) [62]
> Будем вводить. По причине номер раз - для однообразия правил
> формирования таблиц, по причине номер два - для половины
> вводимой информации операторы не знают этих кодов, и знать
> не хотят.
Я ж говорю - с пуристами спорить - себе дороже. Зачем прах Оккама тревожить ?
vuk © (16.04.06 18:32) [65]
> Оно конечно да, но ведь этот ключ в базе потом наверняка
> еще и как внешний будет использоваться. А про то, что ИНН
> могут неверно вбить уже говорили.
Вбить могут неверно все, что угодно. И какая разница, неверно вобьют ИНН или имя, с точки зрения базы данных ?
> В конце концов можно посмотреть на проблему иначе. Уникальна
> конкретная личность, а ИНН - некий атрибут который ей государство
> присвоило и не дело нашей БД, что оно там присвоило и как
> сгенерило.
И, прости, в чем разница, государство сгенерировало или механизм СУБД ?
← →
sniknik © (2006-04-17 11:37) [81]> И какая разница, неверно вобьют ИНН или имя, с точки зрения базы данных ?
исправить сложнее, если конечно ИНН используется как естественный ключь.
← →
Игорь Шевченко © (2006-04-17 11:40) [82]sniknik © (17.04.06 11:37) [81]
Может, я чего здорово не понимаю, но в чем именно сложность ?
← →
Игорь Шевченко © (2006-04-17 11:44) [83]Кроме того, в случае синтетического ключа мне, теоретически, никто не мешает внести несколько одинаковых, ничем не отличающихся сущностей. Например, толпу людей с одинаковыми ИНН, ФИО и т.п.
← →
Jeer © (2006-04-17 12:19) [84]Игорь Шевченко © (17.04.06 11:44) [83]
Уникальный индекс ?
А вообще поддерживаю применение СК (по другому и не делал похоже никогда).
← →
Игорь Шевченко © (2006-04-17 12:24) [85]Jeer © (17.04.06 12:19) [84]
И зачем умножать сущности сверх необходимости ? Тенцера я читал, так что сслку на него в качестве аргумента можно не приводить
← →
Jeer © (2006-04-17 12:28) [86]Игорь Шевченко © (17.04.06 12:24) [85]
> зачем умножать сущности сверх необходимости
Для отделения мух от котлет.
> Тенцера я читал
Не сомневаюсь, однако это известно задолго до появления Тенцера.
← →
Sergey13 © (2006-04-17 12:30) [87]2[85] Игорь Шевченко © (17.04.06 12:24)
>И зачем умножать сущности сверх необходимости ?
Что бы обеспечить себе спокойную старость. 8-)
Ибо ничто не вечно под луной. (с)тырено
Сегодня есть ИНН, завтра нет его, а есть супер-ИНН. Мало ли.
← →
vuk © (2006-04-17 12:34) [88]to Игорь Шевченко © (17.04.06 11:05) [80]:
>Вбить могут неверно все, что угодно. И какая разница, неверно вобьют ИНН
>или имя, с точки зрения базы данных ?
>И, прости, в чем разница, государство сгенерировало или механизм СУБД ?
Мантра есть такая: "Foreign key... Foreign key..." :)
Имя мы уж точно в качестве PK не будем использовать, а вот к чему приведет использование криво вбитого ИНН в качестве FK, я думаю, понятно. Конечно, можно поставить опцию каскадных обновлений.
Ну и еще, если говорить об ИНН в качестве PK, то можно вспомнить, что не у всех оно есть.
Про то, что кто-то может предпочесть не использовать в своей БД чужие идентификаторы в качестве ключевых, я уже упоминал. У нас, например, именно так и есть.
>Кроме того, в случае синтетического ключа мне, теоретически, никто не
>мешает внести несколько одинаковых, ничем не отличающихся сущностей.
Уникальные индексы на то есть. Кстати, в любом случае перед вставкой придется проверку делать, чтобы юзеров непонятными сообщениями сервера не пугать.
← →
McSimm © (2006-04-17 12:34) [89]жизнь немножко сложнее и непредсказуемее, чем твердая логика СУБД. логика "государства" тоже может отличаться от логики вообще...
все это может зависеть от конкретной задачи, конечно. могу добавить несколько аргументов кроме уже приведенных в пользу СК, на примере ИНН
- если ИНН использовать в качестве ключа, нет возможности разграничить секьюрити. например для какого-то рабочего места ИНН не должен быть доступен для просмотра.
- отсутствует возможность временно оставить поле незаполненными (на днях донесу документы),
- мне лично приходилось при заполнении документа вписывать 10 отфонарных цифр вместо реального ИНН, в связи с утверждением в первом абзаце этого поста. я попал в ситуацию, когда ИНН мне был необходим для того, чтобы получить ИНН.
← →
Игорь Шевченко © (2006-04-17 12:40) [90]Jeer © (17.04.06 12:28) [86]
> Для отделения мух от котлет.
С этого места подробнее, где мухи, а где котлеты ?
Sergey13 © (17.04.06 12:30) [87]
> Сегодня есть ИНН, завтра нет его, а есть супер-ИНН. Мало
> ли.
И что ? Я не понимаю, можно на примере пояснить ?
vuk © (17.04.06 12:34) [88]
> Мантра есть такая: "Foreign key... Foreign key..." :)
Да, каждое утро распеваем хором. И что с того ? Давай будем брать не ИНН - пес с ним, а тот самый вариант с кодировкой географии по ISO. Тоже будем ID вводить ?
> а вот к чему приведет использование криво вбитого ИНН в
> качестве FK, я думаю, понятно. Конечно, можно поставить
> опцию каскадных обновлений
Наверное все-таки непонятно, к чему приведет пользование криво вбитого ИНН. Расскажи.
← →
McSimm © (2006-04-17 12:44) [91]
> к чему приведет пользование криво вбитого ИНН
сложно вносить изменения в поля первичного ключа.
в различных СУБД различная степень сложности
> вариант с кодировкой географии по ISO
я бы не стал. есть ограниченный неизменяемый список, ключевое поле одно. смысла вводить индекс, кроме религиозных соображений, нет.
← →
boriskb © (2006-04-17 12:47) [92]Объясните мне о чем спор?
О том, что существует (и не мало) случаев, когда в качестве первичного ключа можно использовать информативное поле базы? В этом есть сомнения?
Или спор о том, что чаще всего удобно использовать автоинкриментный ключ? Об этом тоже надо спорить?
← →
Игорь Шевченко © (2006-04-17 12:48) [93]McSimm © (17.04.06 12:44) [91]
> сложно вносить изменения в поля первичного ключа.
> в различных СУБД различная степень сложности
То есть, существуют СУБД, которые не позволяют изменить значение поля первичного ключа ? Или не обеспечивают соотвествующего обновления подчиненных таблиц ? :)
> кроме религиозных соображений
Об том, собственно, и речь. Любые разумные доводы обычно принимаются, а с религией спорить - нуегонафиг.
← →
Суслик © (2006-04-17 12:48) [94]насчет ИНН я с Игорем не согласен - тут имхо лучше синтетический ключ.
однако есть случаи, когда ключ может быть не синтетический.
например реализация многие-ко-многим посредством третьей таблицы с двумя полями - ид. из первой таблицы, ид. из второй таблицы.
← →
Игорь Шевченко © (2006-04-17 12:48) [95]Суслик © (17.04.06 12:48) [94]
Ты свое имхо пояснишь ?
← →
Суслик © (2006-04-17 12:49) [96]
> [95] Игорь Шевченко © (17.04.06 12:48)
> Ты свое имхо пояснишь ?
Про ИНН? Все просто. У меня вызывают сурьезные опасения последовательность принимающих законы в своих действиях. Не будет завтра ИНН. И что?
← →
Jeer © (2006-04-17 12:50) [97]Игорь Шевченко © (17.04.06 12:40) [90]
> С этого места подробнее, где мухи, а где котлеты ?
мухи - системный уровень (ID, relations)
котлеты - прикладной уровень.
Наличие и уникальность индекса по "котлетам" гарантирует от пользовательских ошибок, в данном случае.
← →
Игорь Шевченко © (2006-04-17 12:50) [98]Суслик © (17.04.06 12:49) [96]
Не будет ИНН - будет другая база, не так ли ?
← →
Суслик © (2006-04-17 12:51) [99]
> [98] Игорь Шевченко © (17.04.06 12:50)
почему?
Люди живы (или контрагенты), работают там же, какого лешего новая база?
← →
Jeer © (2006-04-17 12:51) [100]Игорь Шевченко © (17.04.06 12:48) [93]
> Или не обеспечивают соотвествующего обновления подчиненных
> таблиц ? :)
А то:)
← →
Sergey13 © (2006-04-17 12:52) [101]2[90] Игорь Шевченко © (17.04.06 12:40)
>И что ? Я не понимаю, можно на примере пояснить ?
Да ничего хорошего. Тут либо оставлять "старый ИНН" первичным ключом, но сделать его генеримым в системе, либо заполнять "новый ИНН" у всех записей (сколько их? Когда мы их все получим от клиентов?) и "переводить" систему на него. ИМХО, мало не покажется.
В случае с сурогатом - просто добавим еще одно поле и пропишем правила его заполнения.
>а тот самый вариант с кодировкой географии по ISO. Тоже будем ID вводить ?
Для некоторых данных, возможно, "живой" ключ вполне приемлем. Но, как правило (это из личного опыта), это данные второстепенные - небольшие справочники со стандартизованными данными.
← →
Jeer © (2006-04-17 12:55) [102]Sergey13 © (17.04.06 12:52) [101]
> со стандартизованными данными.
согласен, но и стандарты меняются.
Кроме того, могут быть варианты включения интернациональных обозначений в одну таблицу, т.что ID все же удобней с системных позиций.
← →
McSimm © (2006-04-17 12:57) [103]
> То есть, существуют СУБД, которые не позволяют изменить
> значение поля первичного ключа ? Или не обеспечивают соотвествующего
> обновления подчиненных таблиц ? :)
конечно есть.
но даже если обеспечивают, это может оказаться довольно сложной операцией, по сравнению с единственным изменением поля в единственном справочнике.
на мой взгляд доводов достаточно.
легче изменять, можно не вводить (временно или вовсе. например если речь идет о клиентах, работать с ним уже надо, а ИНН пока отсутствует. из жизни)
Про разграничение доступа довод тоже на мой взгляд не пустой. Насколько я понимаю, ИНН - приватная информация. и легко представить ситуацию, когда не все имеющие доступ к справочнику клиентов имеют право видеть все поля.
← →
Игорь Шевченко © (2006-04-17 12:57) [104]Суслик © (17.04.06 12:51) [99]
> почему?
Ну потому что. Очевидно же, что идентификация по ИНН годится только для вполне вполне определенного ряда задач, а не для пихания ИНН в качестве первичного ключа во все возможные дырки. Пропадет индивидуальный номер налогоплательщика - те задачи потеряют смысл, не так ли ?
Jeer © (17.04.06 12:50) [97]
> мухи - системный уровень (ID, relations)
> котлеты - прикладной уровень.
Мухами в данном случае ведает сама СУБД. Всякие там constraints и прочее.
> Наличие и уникальность индекса по "котлетам" гарантирует
> от пользовательских ошибок, в данном случае.
А ты на примере можешь пояснить ? Желательно из тех областей, которые здесь приводились. От каких ошибок может гарантировать внедрение уникального синтетического ключа ?
← →
Суслик © (2006-04-17 12:58) [105]
> Пропадет индивидуальный номер налогоплательщика - те задачи
> потеряют смысл, не так ли ?
не так ли (и не имхо), налогоплательщик то остался.
← →
McSimm © (2006-04-17 13:00) [106]
> идентификация по ИНН годится только для вполне вполне определенного
> ряда задач
согласен.
это может быть, например, сама база налогоплательщиков.
← →
Суслик © (2006-04-17 13:02) [107]
> согласен.
> это может быть, например, сама база налогоплательщиков.
Да почему? ИНН это одно, налогоплательщик другое.
Если убрать номера автомашин, то что машины уберутся?
← →
Суслик © (2006-04-17 13:03) [108]
> согласен.
> это может быть, например, сама база налогоплательщиков.
Скорее не "налогоплательщиков", а "налогоплательщиков, получисших ИНН".
Это верно
← →
Игорь Шевченко © (2006-04-17 13:04) [109]McSimm © (17.04.06 12:57) [103]
> конечно есть.
> но даже если обеспечивают, это может оказаться довольно
> сложной операцией, по сравнению с единственным изменением
> поля в единственном справочнике.
>
> на мой взгляд доводов достаточно.
Извини, не понимаю. Можно иллюстрацию ?
> Насколько я понимаю, ИНН - приватная информация. и легко
> представить ситуацию, когда не все имеющие доступ к справочнику
> клиентов имеют право видеть все поля
То есть, когда он на кассовом чеке печатается, там приватность не имеет значения, а когда в базе данных, то имеет ? :)
И еще, ко всем - очень трудно схему базы данных рассматривать в отрыве от задач, решаемых с ее помощью. Для общих случаев одинаково неверны и те и другие рекомендации, чаще всего.
← →
McSimm © (2006-04-17 13:05) [110]
> Для общих случаев одинаково неверны и те и другие рекомендации,
> чаще всего.
совершенно согласен
← →
Игорь Шевченко © (2006-04-17 13:05) [111]Суслик © (17.04.06 13:02) [107]
> Да почему? ИНН это одно, налогоплательщик другое.
> Если убрать номера автомашин, то что машины уберутся?
Нет, машины не уберутся. Но отличить их одну от другой станет заведомо труднее.
← →
boriskb © (2006-04-17 13:11) [112]Игорь Шевченко © (17.04.06 13:04) [109]
очень трудно схему базы данных рассматривать в отрыве от задач, решаемых с ее помощью
Так и я про тоже!
Причем здесь ИНН??
Где то он может быть первичным ключом, а где то не может
Разве это не очевидно?
← →
Jeer © (2006-04-17 13:11) [113]Игорь Шевченко © (17.04.06 12:57) [104]
> Мухами в данном случае ведает сама СУБД. Всякие там constraints
> и прочее.
Если может, то - да.
Но иногда и не может:))
А чаще и constraint не помогает и лучше на ХП или на клиенте делать ограничения.
> От каких ошибок может гарантировать внедрение уникального
> синтетического ключа ?
Не синтетического, а сложного индекса по прикладным полям.
← →
Sergey13 © (2006-04-17 13:13) [114]2[109] Игорь Шевченко © (17.04.06 13:04)
> Извини, не понимаю. Можно иллюстрацию ?
Оракл не дает апдейтить каскадно ключ по констрейнту. Можно конечно извратиться, но если по диапазонам ПК, например, настроены партиции, то прикинь во что выльется подобная перекодировка.
← →
Игорь Шевченко © (2006-04-17 13:15) [115]Jeer © (17.04.06 13:11) [113]
> А чаще и constraint не помогает и лучше на ХП или на клиенте
> делать ограничения
Странно. А зачем тогда их (constraints) придумали ? :)
> Не синтетического, а сложного индекса по прикладным полям.
Сложный индекс по прикладным полям - это хорошо. Но не всегда уместно. Возьмем тут же географию по ISO - какие тут можно придумать сложные индексы по прикладным полям, а главное, зачем ? :)
← →
Jeer © (2006-04-17 13:23) [116]Из личных ощущений и практики:
- ФК применяется тогда, когда целесообразно сохранять историю "введения" поля в связанные документы
Пример:
Есть таблица ФАМИЛИИ
Если используется ФК, то в таблицу ПЕРСОНАЛ попадает именно фамилия, а дальнейшее изменение ее в таблице ФАМИЛИИ не приводит к автоматическому изменению в ПЕРСОНАЛ.
Т.е. имеем связь на момент добавления записи в ПЕРСОНАЛ и ее отсутствие в остальное время.
Применение СК же в этом случае приведет к автоматическому изменению фамилии во всех связанных по ID документах.
- СК применяется во всех остальных случаях.
← →
Игорь Шевченко © (2006-04-17 13:23) [117]Sergey13 © (17.04.06 13:13) [114]
> Оракл не дает апдейтить каскадно ключ по констрейнту.
Ну да. Принимается :)
← →
Sergey13 © (2006-04-17 13:26) [118]2[109] Игорь Шевченко © (17.04.06 13:04)
> Для общих случаев одинаково неверны и те и другие рекомендации, чаще всего.
Вобщем да. Но сурогаты будут надежно работать в любой системе, несмотря на некоторое возможное излищество. А живые ключи не в любой системе возможны. А еще хуже, когда сначала вроде возможны, а потом, с развитием или просто течением времени, выясняется, что...
ИМХО.
← →
Игорь Шевченко © (2006-04-17 13:28) [119]Sergey13 © (17.04.06 13:26) [118]
> Вобщем да. Но сурогаты будут надежно работать в любой системе,
> несмотря на некоторое возможное излищество. А живые ключи
> не в любой системе возможны
Здрасьте вам. Это как же живые ключи не в любой системе возможны ? :)
← →
Jeer © (2006-04-17 13:31) [120]Игорь Шевченко © (17.04.06 13:15) [115]
Не у всех СУБД это есть, не у всех работает так, как хочется:))
> Возьмем тут же географию по ISO - какие тут можно придумать
> сложные индексы по прикладным полям, а главное, зачем ?
> :)
Из соображений единообразности работы с таблицами все же ввести ID (PK)
Сложный индекс тут и не нужен.
Но, к примеру, справочник стандартных обозначений чего-то на локальном и англ. языках - что будет PK ?
Как-то эксперементировал с объектным подходом при работе с таблицами.
Такая структура таблицы
ID
[IDL]
NAME
UID
DATER
была использована как базовый класс.
← →
Игорь Шевченко © (2006-04-17 13:37) [121]Jeer © (17.04.06 13:31) [120]
> Из соображений единообразности работы с таблицами все же
> ввести ID (PK)
А каким, извини, образом, в данном случае должны приниматься во внимание соображения единообразности ? Какой выигрыш они дают ?
> Такая структура таблицы
> ID
> [IDL]
> NAME
> UID
> DATER
>
> была использована как базовый класс.
Если ты еще напишешь, какой физический смысл каждого из полей, будет о чем поговорить.
← →
Sergey13 © (2006-04-17 13:37) [122]2[119] Игорь Шевченко © (17.04.06 13:28)
> Здрасьте вам. Это как же живые ключи не в любой системе возможны ? :)
Сори, неправильно выразился.
Вместо
>А живые ключи не в любой системе возможны.
Надо
А живые ключи будут надежно работать НЕ в любой системе.
← →
Игорь Шевченко © (2006-04-17 13:40) [123]Sergey13 © (17.04.06 13:37) [122]
Давай тогда введем определение надежности, чтобы мы оба понимали под одним словом одну и ту же сущность. Ты пойми, если бы естественные ключи несли бы такой потенциальный вред, то во всех СУБД от них бы давно отказались на уровне системы. Неужели от них не отказались только потому, что производители СУБД Тенцера не читали ? :)
← →
Jeer © (2006-04-17 13:41) [124]
> Игорь Шевченко © (17.04.06 13:37) [121]
> Какой выигрыш они дают ?
пример я уже приводил.
Если не введены ограничения на уровне механизма СУБД (их нет или по другим соображениям) - то ID позволяет "автоматически проявлять" изменения в ISO во всех связанных документах.
← →
Игорь Шевченко © (2006-04-17 13:42) [125]Sergey13 © (17.04.06 13:37) [122]
Казалось бы, чего проще - вот есть у каждой таблицы ROWID (в случае с Oracle), вот это и есть первичный ключ. А для ссылочных полей, на уровне СУБД были бы реализованы механизмы поддержки целостности. Чем плохо ? А вот не делают почему-то...
← →
Jeer © (2006-04-17 13:43) [126]Пример
ISO (ID,NAME)
BOOKS (ID, ISO_ID,NAME)
← →
Jeer © (2006-04-17 13:43) [127]
> вот есть у каждой таблицы ROWID (в случае с Oracle),
Своеврмененное уточнение.
← →
Sergey13 © (2006-04-17 13:48) [128]2[123] Игорь Шевченко © (17.04.06 13:40)
Ну вот Оракл не разрешает штатно апдейтить каскадно ключи. Это косвенно и показывает, что не надо естественные использовать. 8-)
Кроме того - а как бы они (производители) отличали естественный от суррогата? По имени что-ли? Так фигня вроде получится. Если вводить новый тип поля - ключ, то вроде надо делать что-то вроде автоинкремента - что не всегда удобно и лишает разработчика свободы формирования ключа по собственной схеме-алгоритму.
← →
Sergey13 © (2006-04-17 13:50) [129]2 [125] Игорь Шевченко © (17.04.06 13:42)
>Казалось бы, чего проще - вот есть у каждой таблицы ROWID (в случае с Oracle), вот это и есть первичный ключ.
Он может являться таковым для одномоментной обработки - типа проапдейтить запись. Однако в более длительный период времени ROWID может меняться и потому не может быть ключом для связей.
← →
Jeer © (2006-04-17 13:57) [130]Sergey13 © (17.04.06 13:50) [129]
> автоинкремента
> ROWID может меняться
По этой же причине и autoinc "опасен"
← →
Игорь Шевченко © (2006-04-17 13:59) [131]Sergey13 © (17.04.06 13:48) [128]
> Кроме того - а как бы они (производители) отличали естественный
> от суррогата?
А никак. Вводили бы только суррогатный и всех дел.
> Ну вот Оракл не разрешает штатно апдейтить каскадно ключи.
> Это косвенно и показывает, что не надо естественные использовать.
> 8-)
Ну, во-первых, никто не мешает реализовать такой апдейт в триггере путем insert|delete.
Jeer © (17.04.06 13:41) [124]
> - то ID позволяет "автоматически проявлять" изменения в
> ISO во всех связанных документах.
А по какой причине эти изменения возникнут, что их надо "автоматически проявлять" ?
Jeer © (17.04.06 13:43) [126]
> Пример
Извини, не понимаю. Если не затруднит, то для бестолковых два раза и помедленнее.
← →
Суслик © (2006-04-17 14:01) [132]
> [111] Игорь Шевченко © (17.04.06 13:05)
> > Да почему? ИНН это одно, налогоплательщик другое.
> > Если убрать номера автомашин, то что машины уберутся?
> Нет, машины не уберутся. Но отличить их одну от другой станет
> заведомо труднее.
Вот поэтому и не надо использовать ИНН в качестве ключа, чтобы не пропала возможность отличать одного налогоплательщика от другого. Очевидно же.
← →
Игорь Шевченко © (2006-04-17 14:01) [133]Sergey13 © (17.04.06 13:50) [129]
> Он может являться таковым для одномоментной обработки -
> типа проапдейтить запись. Однако в более длительный период
> времени ROWID может меняться и потому не может быть ключом
> для связей.
Как ты понимаешь, никто не мешает разработчику сделать неизменяемый ROWID.
> Так фигня вроде получится. Если вводить новый тип поля -
> ключ, то вроде надо делать что-то вроде автоинкремента
> - что не всегда удобно
Ну как же не всегда удобно - целую ветку ведется дискуссия о том, что искусственные ключи есть рулез немеряный и удобны во всех отношениях, как вдруг выясняется, что "фигня получается".
← →
Игорь Шевченко © (2006-04-17 14:03) [134]Суслик © (17.04.06 14:01) [132]
Я тебе еще раз повторю - я не агитирую за то, чтобы ИНН, а также дату рождения, пол вес и прочие массогабаритные характеристики делать ВО ВСЕХ случаях первичными ключами. Но если ключом сделано, то при пропадании его в реальной жизни задача, для которой он вводился, просто потеряет смысл и никакой ID тебя не спасет.
← →
Sergey13 © (2006-04-17 14:05) [135]2[131] Игорь Шевченко © (17.04.06 13:59)
>А никак. Вводили бы только суррогатный и всех дел.
Что значит "вводили бы"? Сами что-ли? Так это типа чистый автоикремент, который нельзя узнать до вставки (и вообще управлять им нельзя) и потому неудобен для работы.
> Ну, во-первых, никто не мешает реализовать такой апдейт в триггере путем insert|delete.
Так никто не спорит, что можно обойти. Но штатно нельзя.
Кроме того не хотел бы я ждать завершения подобной (тригерной) перекодировки на приличной по размерам базе. 8-)
← →
vuk © (2006-04-17 14:06) [136]to Игорь Шевченко:
>Давай будем брать не ИНН - пес с ним, а тот самый вариант с кодировкой
>географии по ISO. Тоже будем ID вводить ?
На это я уже ответил.
см. vuk © (16.04.06 18:32) [65]
← →
Sergey13 © (2006-04-17 14:07) [137]2 [133] Игорь Шевченко © (17.04.06 14:01)
> Как ты понимаешь, никто не мешает разработчику сделать неизменяемый ROWID.
Это как? Запретить узеру работать с базой что-ли?
← →
Jeer © (2006-04-17 14:07) [138]Игорь Шевченко © (17.04.06 13:59) [131]
> А по какой причине эти изменения возникнут, что их надо
> "автоматически проявлять" ?
По причине изменения стандарта (RUS изменилось на RAS)
Пример
ISO (ID,NAME)
BOOKS (ID, ISO_ID,NAME)
select B.*, I.NAME AS ISO_NAME
from BOOKS B, ISO I
where B.ISO_ID = I.ID
ISO_NAME всегда будет иметь измененное знчение из ISO.NAME для произвольно взятой СУБД (не использование ограничений)
т.к. меняется не первичный ключ, а прикладное поле.
← →
Jeer © (2006-04-17 14:09) [139]vuk © (17.04.06 14:06) [136]
Во !
Почитал vuk и понял что мы об одном и том же - одинаково.:))
← →
Суслик © (2006-04-17 14:10) [140]
> [134] Игорь Шевченко © (17.04.06 14:03)
Ты разницу между "База налогоплательщиков" и "База людей получивших ИНН?" понимаешь?
← →
Игорь Шевченко © (2006-04-17 14:16) [141]Jeer © (17.04.06 14:07) [138]
> По причине изменения стандарта (RUS изменилось на RAS)
Если стандарт изменился, то это будет уже другой стандарт, как ты понимаешь. А в случае изменения кода, для другого кода это будет другая сущность.
vuk © (17.04.06 14:06) [136]
Ответил. Но я честно не понимаю, с какого боку тут однородность методики идентификации записей. Почему тогда производители СУБД не делают штатно такую возможность ? Наш форум не читают ?
Sergey13 © (17.04.06 14:05) [135]
> Что значит "вводили бы"? Сами что-ли? Так это типа чистый
> автоикремент, который нельзя узнать до вставки (и вообще
> управлять им нельзя) и потому неудобен для работы.
Вот замечательно. А как ты суррогатным ключом управляешь ?
> > Как ты понимаешь, никто не мешает разработчику сделать
> неизменяемый ROWID.
> Это как? Запретить узеру работать с базой что-ли?
Зачем запрещать ? А что, пользователь непременно ROWID меняет при своей работе с базой данных ?
← →
Игорь Шевченко © (2006-04-17 14:16) [142]Суслик © (17.04.06 14:10) [140]
Я понимаю. А какое отношение твоя фраза к теме ветки имеет ?
← →
vuk © (2006-04-17 14:34) [143]to Игорь Шевченко © (17.04.06 14:16) [141]:
>Но я честно не понимаю, с какого боку тут однородность методики
>идентификации записей.
А при том. Чтобы не было как в той байке - "здесь играть, здесь не играть, здесь рыбу заворачивали".
>Почему тогда производители СУБД не делают штатно такую возможность ?
Естественных ключей иногда хватает, а иногда нет. Принуждать всегда пользоваться искусственными тоже неправильно.
← →
Суслик © (2006-04-17 14:39) [144]
> Я понимаю. А какое отношение твоя фраза к теме ветки имеет
> ?
Ты игнорируешь невыгодные тебе в данном контексте доводы. Например, довод о том, что база "Налогоплательщиков" никакого отношения к ИНН не имеет: налогоплательщики есть, а есть ли у них ИНН это вопрос другой. Вот у меня и сложилось ощущение, что разница между базой "Налогоплательщиков" и "Людей получивших ИНН" тебе не совсем ясна или просто ты не обратил на эту разницу внимания. И я посчитал своим долгом обратить на это внимание человека, который принимает участие в данной конкретной ветке. Вроде объяснил.
← →
Sergey13 © (2006-04-17 14:39) [145]2 [141] Игорь Шевченко © (17.04.06 14:16)
> Вот замечательно. А как ты суррогатным ключом управляешь ?
Очень просто. Я могу например менять диапазон значений ключа в зависимости от внешних факторов (например для разграничения филиалов для "а-ля" репликации) . Я могу заранее узнать следующее значение ключа для вставки связанных данных. И т.п.
> Зачем запрещать ? А что, пользователь непременно ROWID меняет при своей работе с базой данных ?
Он его может изменить штатными незапрещенными методами. Например импорт/экспорт или перенос данных на другой диск и многими другими.
← →
Игорь Шевченко © (2006-04-17 14:47) [146]vuk © (17.04.06 14:34) [143]
> Естественных ключей иногда хватает, а иногда нет. Принуждать
> всегда пользоваться искусственными тоже неправильно.
Ты сказал! (с) Евангелие.
Ключевая фраза - "Естественных ключей иногда хватает". Об чем, собственно, большевики и твердят на протяжении всей этой ветки.
> А при том. Чтобы не было как в той байке - "здесь играть,
> здесь не играть, здесь рыбу заворачивали".
Ты сам себе не противоречишь ? :)
Суслик © (17.04.06 14:39) [144]
Видишь ли, я тебе могу еще раз повторить фразу, что всякая схема базы данных имеет смысл для определенного круга задач. Ты же начинаешь вводить новые условия (сегодня ИНН есть, а завтра его отменят), не принимая во внимание, например, тот факт, что с отменой ИНН ряд задач просто потеряет смысл.
> Ты игнорируешь невыгодные тебе в данном контексте доводы.
>
У меня, дорогой Дима, вообще никакой выгоды от этой дискусии нет. Ни я никого не принуждаю, ни меня никто не принуждает.
Sergey13 © (17.04.06 14:39) [145]
> Он его может изменить штатными незапрещенными методами.
> Например импорт/экспорт или перенос данных на другой диск
> и многими другими.
Точно также сгенерированный суррогатный ключ после экспорта /импорта может потерять смысл.
← →
Sergey13 © (2006-04-17 14:49) [147]2Sergey13 © (17.04.06 14:39) [145]
> Точно также сгенерированный суррогатный ключ после экспорта /импорта может потерять смысл.
Почему?
← →
vuk © (2006-04-17 14:55) [148]to Игорь Шевченко © (17.04.06 14:47) [146]:
>Об чем, собственно, большевики и твердят на протяжении всей этой ветки.
А я, собственно, это сомнению и не подвергал.
>Ты сам себе не противоречишь ? :)
Нет.
← →
Игорь Шевченко © (2006-04-17 14:56) [149]Sergey13 © (17.04.06 14:49) [147]
Например по причине совпадения значений сгенерированных ключей со сгенерированными в другой отрезок времени либо при экспорте из одной базы данных со своей последовательностью генерации и импорте данных в базу с другой последовательностью.
Дабы всем была понятна моя позиция, я ее озвучу: Всякий овощ приносит пользу, будучи употреблен надлежащим образом в надлежащее время. Естественные ключи в ряде случаев являются удобными к применению и смысла не употреблять их только потому, что в других случаях они неудобны, я не вижу. Более того, если бы ествественные ключи были бы однозначно неудобны/чреваты последствиями, то производители СУБД давно бы сделали прозрачный механизм для связи таблиц. Поскольку я такого механизма не наблюдаю в тех СУБД, с которыми приходится иметь дело (Interbase, Oracle), то следовательно, либо производители этого не делают, либо я чего-то искать не умею.
← →
McSimm © (2006-04-17 14:57) [150]
> Sergey13 © (17.04.06 14:49) [147]
> Почему?
потому что покинул границы целостности данных
← →
Sergey13 © (2006-04-17 15:08) [151]2[149] Игорь Шевченко © (17.04.06 14:56)
>Например по причине совпадения значений ...
Это если в лоб делать все_равно_какой экспорт в непустую таблицу (я, применительно к ROWID, говорил о полном импорте/экспорте схемы/БД). Для тех же филиалов с диапазонами ключей экспорт в "общую БД" пройдет нормально и без коллизий.
>Дабы всем была понятна моя позиция, я ее озвучу
8-)
← →
Jeer © (2006-04-17 15:17) [152]McSimm © (17.04.06 14:57) [150]
> потому что покинул границы целостности данных
Если autoinc - да.
Вот почему их не люблю:))
Игорь Шевченко © (17.04.06 14:16) [141]
> Если стандарт изменился, то это будет уже другой стандарт,
> как ты понимаешь. А в случае изменения кода, для другого
> кода это будет другая сущность.
Нет, прикладная сущность не изменилась - все та же Russia, но код поменялся.
Наличие CR позволяет, в данной ситуации, внести изменение только в справочник.
Игорь Шевченко © (17.04.06 14:56) [149]
Это частное мнение.
Точно с таким же - считаю, что наличие искусственных хотя и усложняет join, но в конечном итоге приводит к большим устойчивости, корректности, производительности.
Для коротких естественных ключей - все понятно, можно использовать, но с учетом универсальности - имеет смысл перейти на искусственные.
Длинные естественные ключи - источних проблем при миграции во ВК.
Они вообще - проблема, эти ЕК, т.к. являются порождением внешней среды, а не БД.
← →
Игорь Шевченко © (2006-04-17 15:21) [153]Jeer © (17.04.06 15:17) [152]
> Нет, прикладная сущность не изменилась - все та же Russia,
> но код поменялся.
По какой причине код поменялся ? :)
> Для коротких естественных ключей - все понятно, можно использовать,
> но с учетом универсальности - имеет смысл перейти на искусственные.
>
Вот чего я не могу понять - это привлечение в качестве аргумента "универсальности". Любое попытка универсализировать что-либо в большинстве случаев приводит к неэффективности и прочим побочным эффектам. Как говорится в законах Мэрфи - всякое решение плодит новые проблемы.
← →
Jeer © (2006-04-17 15:32) [154]Игорь Шевченко © (17.04.06 15:21) [153]
> По какой причине код поменялся ? :)
Это не суть.
> Любое попытка универсализировать
является попыткой систематизации, в первую очередь, что не может благотворно не сказаться на проектировании системы.
Кроме, того СК являются более гибким решением и позволяют вести пере- до-проектирование системы с меньшими потерями.
← →
Jeer © (2006-04-17 15:34) [155]А вообще-то СК vs ЕК - давно отнесено к войнам религиозного типа.
А проектировщики СУБД не отдают предпочтения чьей-либо стороне по философским убеждениям.:)
← →
Игорь Шевченко © (2006-04-17 15:42) [156]Jeer © (17.04.06 15:32) [154]
> Это не суть.
Нет, Сергей, именно в этом и суть. Просто так ничего не может меняться и всякое подобное изменение может (а в большистве случаев и должно) повлечь за собой изменение в алгоритме.
> Кроме, того СК являются более гибким решением и позволяют
> вести пере- до-проектирование системы с меньшими потерями.
>
Не вижу причины, почему бы не использовать естественные ключи при перепроектировании системы.
> является попыткой систематизации, в первую очередь
Если внесение лишних сущностей называется систематизацией, то я, извини, против такой систематизации, потому как побочным эффектом от такой огульной систематизации является головная боль.
← →
Sergey13 © (2006-04-17 15:53) [157]2[156] Игорь Шевченко © (17.04.06 15:42)
> Если внесение лишних сущностей называется систематизацией, то я, извини, против такой систематизации
Так то "лишних сущностей". А СК - не лишний, он дополнительный и независимый. 8-)
А первоначально, многие ЕК были обычными СК. Потом к ним привыкли и они стали естественными. Те-же ИНН, номера паспортов и тому подобная билиберда. 8-)
← →
Игорь Шевченко © (2006-04-17 15:58) [158]Sergey13 © (17.04.06 15:53) [157]
> Так то "лишних сущностей". А СК - не лишний, он дополнительный
> и независимый
Ну да. Дополнительным является пятое колесо в телеге :)
← →
Sergey13 © (2006-04-17 16:00) [159]2[158] Игорь Шевченко © (17.04.06 15:58)
> Ну да. Дополнительным является пятое колесо в телеге :)
Пятое колесо - это запаска! Я без нее не рискну выехать. 8-)
← →
Anatoly Podgoretsky © (2006-04-17 16:05) [160]Суслик © (17.04.06 12:49) [96]
Не будет завтра ИНН. И что?
Да ничего, как был в твоей базе так и остался. И новые можно выдавать без оглядки на государство, просто ИНН превратится логически в UID
← →
Суслик © (2006-04-17 16:13) [161]
> просто ИНН превратится логически в UID
1. вот и придумывай алгоритм придумывания новых ИНН если оный "умрет".
2. вот и храни 10(+длина строки) знаков вместо 4 (int).
а надо оно?
← →
Jeer © (2006-04-17 16:17) [162]Игорь Шевченко © (17.04.06 15:42) [156]
1. PK - это способ идентификации записи в пределах таблицы, не более того.
С этой точки зрения, что СК, что EK - неважно, т.к. не стоит задача идентификации с внешним миром.
1а - РК на основе СК и связки таблиц на основе СК - "естественнее" для СУБД.
2. ЕК, тем более составной ЕК, привязанный к изменчивому внешнему миру и есть основной источник головной боли.
3. Систематизации и на ее основе разумная унификация ничего, кроме лучших понимания и управляемости системы принести не может.
"Или не тот корм был в коня" (С)
4. В принципе, СК и ЕК - это разные уровни абстракции одного и того же - прикладных данных, но, как правило, с использованием СК система работает быстрее, проектирование ведется единообразнее (тот самый универсализм).
← →
Jeer © (2006-04-17 16:19) [163]Anatoly Podgoretsky © (17.04.06 16:05) [160]
Переехал чел из Воркуты в Москву - смотришь и новый ИНН достался.
А чел. один и тот же.
Где уж тут уникальность.
← →
Игорь Шевченко © (2006-04-17 16:27) [164]Jeer © (17.04.06 16:19) [163]
Раз он переехал, то какой смысл его учитывать ?
Jeer © (17.04.06 16:17) [162]
> 1а - РК на основе СК и связки таблиц на основе СК - "естественнее"
> для СУБД.
Что значит - естественнее ? С точки зрения СУБД абсолютно безразлично, какой первичный ключ - всего лишь поле или набор полей в таблице.
> 2. ЕК, тем более составной ЕК, привязанный к изменчивому
> внешнему миру и есть основной источник головной боли.
У СУБД голова не болит, как ты понимаешь. Составной просто неудобен, не более того, потому что каждая связанная таблица вынуждена хранить копии значений. Насчет изменчивости внешнего мира - а всякая ли изменчивость должна поддаваться учету в рамках конкретных задач ?
> 3. Систематизации и на ее основе разумная унификация ничего,
> кроме лучших понимания и управляемости системы принести
> не может.
Может принести. Например, если к заведомо неизменным в рамках задачи сущностям, естественно идентифицирующих себя одним из своих атрибутов, в угоду унификации, будет приделан искусственный ключ, он послужит скорее головной болью или потерей производительности.
← →
Sergey13 © (2006-04-17 16:30) [165]2[164] Игорь Шевченко © (17.04.06 16:27)
Ты часто упоминаешь "рамках конкретных задач", " неизменным в рамках задачи сущностям". Но эти "рамки" - одно из самых непостоянных условий во внешнем мире, которые касаются программистов. 8-)
← →
Игорь Шевченко © (2006-04-17 16:35) [166]Sergey13 © (17.04.06 16:30) [165]
Ну не знаю. Если предметная область устойчивая, то откуда возьмется непостоянность ?
← →
Jeer © (2006-04-17 16:38) [167]Игорь Шевченко © (17.04.06 16:27) [164]
> Раз он переехал, то какой смысл его учитывать ?
Имеет, т.к. он мог переехать в пределах одной учетной базы и формально будет два налогоплательщика, но один чел.
> С точки зрения СУБД абсолютно безразлично,
Еще как различно:)
СУБД - она к машинке ближе, а там integer в почете.
> У СУБД голова не болит, как ты понимаешь.
Зато болит у разработчика при смене реалий по два раза на день.
> Составной просто неудобен,
Не просто, а очень, т.к. балшой и СУБД его на быстро скушает.
> а всякая ли изменчивость должна поддаваться учету в рамках
> конкретных задач ?
Если это о том, что на каждый чих органов должны выделяться деньги на его вытирание -это утопия.
Сказано сменить план счетов ?
Сделано.
Всем ли оплачено - некоторым.
> или потерей производительности.
справочники, как правило невелики по объему, ссылки же по связкам-integer эффективнее для СУБД, т.е быстрее.
Все это - как правило.
Исключения мизерны, а потому - ничтожны.
← →
Sergey13 © (2006-04-17 16:41) [168]2[166] Игорь Шевченко © (17.04.06 16:35)
>Ну не знаю. Если предметная область устойчивая, то откуда возьмется непостоянность ?
Так вот например, было как
[163] Jeer © (17.04.06 16:19)
Переехал чел из Воркуты в Москву - смотришь и новый ИНН достался.
[164] Игорь Шевченко © (17.04.06 16:27)
Раз он переехал, то какой смысл его учитывать ?
А потом решили распространить Воркутинский опыт и потребовалось все слить "в мировом масштабе".
Да мало ли. ПисАли "складик для себя", а потом получилось почти "ERP на продажу".
← →
Игорь Шевченко © (2006-04-17 16:47) [169]Jeer © (17.04.06 16:38) [167]
> Имеет, т.к. он мог переехать в пределах одной учетной базы
> и формально будет два налогоплательщика, но один чел.
Тогда все зависит от того, как его, переехавшего надо учитывать. Пока ты не ответишь на этот вопрос, дальнейшая дискуссия нецелесообразна.
> Еще как различно:)
> СУБД - она к машинке ближе, а там integer в почете.
Точно ? А вот в MSSQL, по публикациям, GUID рекомендуют. А он и вовсе не Integer. Да и ROWID у Oracle тоже не Integer. Поэтому что там куда ближе - это еще бабушка надвое сказала.
> Если это о том, что на каждый чих органов должны выделяться
> деньги на его вытирание -это утопия.
> Сказано сменить план счетов ?
> Сделано.
Сергей, дело в том, что для меня слова "план счетов" - это полный санскрит и если ты думаешь, что сочетание "сменить план счетов" для меня что-то значит, то я, увы, вынужден тебя разочаровать.
> Зато болит у разработчика при смене реалий по два раза на
> день.
Зачем их менять, два раза в день, реалии-то ? :) Ну в упор не понимаю.
> ссылки же по связкам-integer эффективнее для СУБД, т.е быстрее.
Эта...Ходят слухи, что СУБД внутре себя integer"ы не используют для идентификации записей в таблицах...
← →
Jeer © (2006-04-17 16:48) [170]В общем, хотелось бы завершить данную полемику тем, что выбор СК vs ЕК - вопрос практический или философский, но не теоретический, т.е. формальных методов обоснования предпочтения пока не видно.
← →
Игорь Шевченко © (2006-04-17 16:52) [171]Jeer © (17.04.06 16:48) [170]
Вот с этим я безусловно соглашусь :)
← →
Jeer © (2006-04-17 16:54) [172]
> Точно ? А вот в MSSQL, по публикациям, GUID рекомендуют.
> А он и вовсе не Integer.
> Ходят слухи, что СУБД внутре себя integer"ы не используют
> для идентификации записей в таблицах...
>
Реализации они разные бывают, да и что Микрософту лишние гигабайты.
А проверить легко - тестик:
Таблицы:
ФАМИЛИИ (char 32)
ИМЕНА (32)
ОТЧЕСТВА (32)
ПЕРСОНАЛ(Ф,И,О, ИНН)
Один вариант на СК, другой на ЕК
записей по 100 на справочники и 500 тыс на ПЕРСОНАЛ
Вот и проверка будет:)
← →
Игорь Шевченко © (2006-04-17 16:57) [173]Jeer © (17.04.06 16:54) [172]
> Таблицы:
> ФАМИЛИИ (char 32)
> ИМЕНА (32)
> ОТЧЕСТВА (32)
> ПЕРСОНАЛ(Ф,И,О, ИНН)
>
> Один вариант на СК, другой на ЕК
> записей по 100 на справочники и 500 тыс на ПЕРСОНАЛ
Если честно - не понял. Ты предлагаешь Фамилии хранить в отдельной таблице, Имена в отдельной таблице ? А зачем ? :)
← →
Jeer © (2006-04-17 17:09) [174]Это пример работы со справочниками, как соответствующий реальности.
← →
VictorT © (2006-04-17 17:15) [175]
> Точно не помню, но алгоритм ведет к тому, что можно
> расшифровать дату рождения и пол и исключены
> совпадения.
Теоретически - да, а практически - то ли алгоритму не всегда следуют, то ли фиг знает какие причины, но неоднократно видел совпадения (неднократно - это десятки раз).
← →
Игорь Шевченко © (2006-04-17 17:19) [176]Jeer © (17.04.06 17:09) [174]
Объем данных - это одна половина вопроса. Вторая половина - это характер запросов к этим данным. Я не уверен, что заранее, не зная задачи, склонюсь к использованию естественных или искусственных ключей.
← →
Jeer © (2006-04-17 17:22) [177]Выборки по:
- фамилии
- фам + имени
- ф + и + о
← →
Игорь Шевченко © (2006-04-17 17:37) [178]Jeer © (17.04.06 17:22) [177]
В таком случае я, скорее всего, выберу естественные ключи.
← →
euru © (2006-04-17 17:42) [179]Странный спор.
Я знаю одну большую систему, работающую не только в нашей стране. Так там успешно применяются оба типа РК. И, вроде бы, никаких проблем эта система не испытывает.
Об чём же тогда спор?
← →
Внук © (2006-04-17 19:15) [180]>>Игорь Шевченко © (17.04.06 11:05) [80]
А спорить не надо, просто приведи хоть одну причину делать естественный первичный ключ, кроме непонятной любви к мазохизму.
Первичный ключ, допускающий редактирование пользователем - страшный сон. Но любителям приключений, в отличие от пуристов - удачи.
← →
Внук © (2006-04-17 19:20) [181]>>Игорь Шевченко © (17.04.06 12:48) [93]
>>Любые разумные доводы обычно принимаются, а с религией спорить - нуегонафиг.
Есть и еще доводы, кроме уже приведенных (которых и так выше крыши). Но я опять подозреваю тебя в споре ради спора :)
← →
Внук © (2006-04-17 19:29) [182]Sergey13 © (17.04.06 13:26) [118]
В точку.
← →
euru © (2006-04-17 20:31) [183]
> Внук © (17.04.06 19:15) [180]
>
> >>Игорь Шевченко © (17.04.06 11:05) [80]
> А спорить не надо, просто приведи хоть одну причину делать
> естественный первичный ключ, кроме непонятной любви к мазохизму.
>
Номер документа + Дата проводки
Позволяет сократить количество операторов JOIN, которые неминуемо бы появились, будь у каждого документа суррогатный автоинкрементный код.
← →
Lamer@fools.ua © (2006-04-17 20:42) [184]>Номер документа + Дата проводки
Позволяет сократить количество операторов JOIN, которые неминуемо бы появились, будь у каждого документа суррогатный автоинкрементный код.
Можно пояснить это на примере? Я что-то не вижу причин для уменьшения количества JOIN"ов.
К тому же, судя по слову "проводка" речь идёт о бухгалтерской системе? Если да, то ещё вопрос: а если документ ещё не проведен, а только пока что сохранён?
← →
Внук © (2006-04-17 20:42) [185]Каким образом вид ключа влияет на количество операторов JOIN? Правда, не понимаю. Суррогатный ключ, состоящий из одного поля, наоборот упрощает связи. А вот связывать таблицы по информационным полям... Брр.
← →
Внук © (2006-04-17 20:52) [186]Вобщем, я тоже сформулирую свою точку зрения. То, что можно придумать задачу, где естественный ключ не несет вреда - понятно. Иначе не было бы предмета спора. Но как аргумент - очень слабо. При отсутствии реальных плюсов кроме общей фразы о ненужности плодить лишние сущности (которые имхо совсем не лишние), естественные ключи чреваты - как из-за нестабильности законодательства, так и при сопровождении и дальнейшем развитии систем или их интеграции в более сложные. Не говоря о введении общих правил формирования таблиц и именований на основе Case-средств. Выделять те редкие случаи, когда естественный ключ допустим - играть в рулетку - не порекомендовал бы даже профессионалам, не говоря о новичках, с вопроса которого все и началось.
Насчет пресловутого кода ISO. Как я уже сказал - есть такой справочник у нас. В действительности, сделай мы это поле первичным ключом - то есть обязательным для ввода - рисковали бы остановить работу программы, что в нашем случае чревато серьезными проблемами вплоть до потери заказчика. Из странной любви к искусству такие вещи нет желания воплощать.
← →
xayam © (2006-04-17 23:59) [187]
> euru © (17.04.06 17:42) [179]
> Странный спор.
>
> Я знаю одну большую систему...И, вроде
> бы, никаких проблем эта система не испытывает.
>
> Об чём же тогда спор?
Вопрос был не в том испытывает она проблемы по жизни или нет, вопрос в способности системы (базы данных) к адаптации к изменениям в реальной жизни (ИНН, ISO... ... ...). Если Вы используете Естеств.Ключ могу Вас поздравить - гемороя не оберетесь (еще раз повторю [30]: а оно Вам надо?), при наличии же Сур.Ключа эти изменения сведены к минимуму.
> Игорь Шевченко ©
[90] -1
[98] -1
[111] -1
[115] -1
[121] -1
[131] -1
[134] -1
...дальше не читал...итого < -7
← →
Суслик © (2006-04-18 00:39) [188]
> xayam © (17.04.06 23:59) [187]
поддерживаю.
---------------
повторю, что для меня единственное место ествественного ключа (как я понимаю, это когда в PK включается не уникальный суррогат, а значение) это junction table - таблица связи в отношении многие ко многим.
← →
xayam © (2006-04-18 00:58) [189]
> Суслик © (18.04.06 00:39) [188]
> это когда в PK включается не уникальный
> суррогат, а значение
PK по определению уникальный каким бы он ни был, ЕК или СК
← →
Игорь Шевченко © (2006-04-18 10:14) [190]Внук © (17.04.06 20:52) [186]
> Насчет пресловутого кода ISO. Как я уже сказал - есть такой
> справочник у нас. В действительности, сделай мы это поле
> первичным ключом - то есть обязательным для ввода - рисковали
> бы остановить работу программы, что в нашем случае чревато
> серьезными проблемами вплоть до потери заказчика.
А зачем вы пишете такие программы ? Я бы не стал тратить время.
Внук © (17.04.06 19:15) [180]
> А спорить не надо, просто приведи хоть одну причину делать
> естественный первичный ключ
Причина простая - брать и делать. Или вопрос настолько заумный, что я его не понимаю.
xayam © (17.04.06 23:59) [187]
> Вопрос был не в том испытывает она проблемы по жизни или
> нет, вопрос в способности системы (базы данных) к адаптации
> к изменениям в реальной жизни
Примеры адаптации в студию. Без примеров твои слова пустой звон.
> ...дальше не читал...итого < -7
Вот и хорошо, арифметику усвоил.
← →
Anatoly Podgoretsky © (2006-04-18 10:19) [191]Игорь Шевченко © (18.04.06 10:14) [190]
Или вопрос настолько заумный, что я его не понимаю.
Религиозный.
← →
Внук © (2006-04-18 10:24) [192]>>Игорь Шевченко © (18.04.06 10:14) [190]
>>А зачем вы пишете такие программы ?
Вот в этом, скорее всего, и корень спора. Видишь ли, если писать и продавать коробочный продукт, то можно следовать заветам всяких Бекусов и братьев их Науэров. Подходит продукт заказчику - берет, не подходит - ну и ладно. Мы же пишем всегда под конкретного заказчика, поэтому система обречена на развитие, сопровождение, ввод новых версий, подгонку под капризы и т.д. В данном случае естественные ключи даже на очевидных справочниках - куча проблем. Можно спорить, но я больше верю собсвтенному опыту, чем абстрактным рассуждениям.
← →
Игорь Шевченко © (2006-04-18 10:32) [193]Внук © (18.04.06 10:24) [192]
Да кто бы спорил - заказчики, они такие. Но какое отношение поведение заказчиков имеет к сабжу, я честно не понимаю.
← →
Игорь Шевченко © (2006-04-18 10:37) [194]Внук © (17.04.06 20:52) [186]
> естественные ключи чреваты - как из-за нестабильности законодательства
Дорогой Саша, на свете, кроме бухгалтерии, существует еще масса не менее увлекательных предметных областей.
"Их тоже следует убивать" (с) Страж-птица.
> Выделять те редкие случаи, когда естественный ключ допустим
> - играть в рулетку - не порекомендовал бы даже профессионалам,
> не говоря о новичках, с вопроса которого все и началось.
>
>
Я бы не сказал, что они такие уж редкие. Почему, интересно, авторы книжек по СУБД не рекомендуют, все как один, использовать исключительно синтетические ключи ? Они в другом мире живут ?
← →
Внук © (2006-04-18 10:38) [195]>>Игорь Шевченко © (18.04.06 10:32) [193]
А я не понимаю, какое отношении имеет частный случай, когда ЕК не несет проблем, к преимуществам и недостаткам обсуждаемых методик.
← →
Игорь Шевченко © (2006-04-18 10:54) [196]Внук © (18.04.06 10:38) [195]
А я еще раз могу повторить про овощи. Про преимущества и недостатки уже 195 постов обсуждаем. У естественных ключей преимущество в первую очередь в простоте программирования, а как ты сам понимаешь, чем проще программировать, тем меньше ошибок и тем легче сопровождать систему.
← →
Sergey13 © (2006-04-18 11:00) [197]2[196] Игорь Шевченко © (18.04.06 10:54)
> У естественных ключей преимущество в первую очередь в простоте программирования
А чем проще то? Или в чем сложность СК?
← →
Игорь Шевченко © (2006-04-18 11:05) [198]Sergey13 © (18.04.06 11:00) [197]
> А чем проще то?
Запросы проще писать, полей меньше.
← →
vuk © (2006-04-18 11:07) [199]to Игорь Шевченко © (18.04.06 10:54) [196]:
>У естественных ключей преимущество в первую очередь в простоте
>программирования
Если естественный ключ составной, то программирование не упрощается, а только усложняется.
← →
Lamer@fools.ua © (2006-04-18 11:07) [200]>У естественных ключей преимущество в первую очередь в простоте программирования, а как ты сам понимаешь, чем проще программировать, тем меньше ошибок и тем легче сопровождать систему.
IMHO, очень спорное утверждение. Почему, когда я пишу JOIN в запросе, я должен вспоминать, по какому полю (или, упаси Аллах, полям) мне нужно соединять таблицы в ON?
← →
Игорь Шевченко © (2006-04-18 11:10) [201]vuk © (18.04.06 11:07) [199]
А скажи мне пожалуйста, зачем производители СУБД допускаю.т возможность задания составных ключей ? Чтобы бедным программистам и пользователям мозги засорить ?
Ну вот интересно мне :)
← →
Sergey13 © (2006-04-18 11:14) [202]2 [201] Игорь Шевченко © (18.04.06 11:10)
>зачем производители СУБД допускаю.т возможность задания составных ключей ?
Они просто оставляют свободу выбора разработчику. Только и всего. А ты думаешь они их этим пропагандируют?
← →
Игорь Шевченко © (2006-04-18 11:26) [203]Sergey13 © (18.04.06 11:14) [202]
> Они просто оставляют свободу выбора разработчику. Только
> и всего. А ты думаешь они их этим пропагандируют?
Нет, я далек от мысли о какой-либо пропаганде. Я полагаю, что разработчики СУБД допускают использование как естественных, так и искусственных ключей, только и всего. И принимать за догму один из этих вариантов и следовать только ему, по меньшей мере недальновидно.
← →
vuk © (2006-04-18 11:26) [204]to Игорь Шевченко © (18.04.06 11:10) [201]:
>А скажи мне пожалуйста, зачем производители СУБД допускаю.т
>возможность задания составных ключей ?
Ну ты ж понимаешь. Им надо стричь бабки с приверженцев обеих религий.:o)
Не всегда первичный составной ключ мешает. Например, тогда, когда он внешним не будет. Иначе это приводит к усложнению запросов и дублированию данных.
← →
euru © (2006-04-18 11:27) [205]
> Lamer@fools.ua © (17.04.06 20:42) [184]
>
> К тому же, судя по слову "проводка" речь идёт о бухгалтерской
> системе? Если да, то ещё вопрос: а если документ ещё не
> проведен, а только пока что сохранён?
1. При создании любого бухгалтерского документа (в нашей системе) делается проводка. Так что сохранённых, но непроведённых бухгалтерских документов нет.
2. Однако создавать документы без даты проводки можно. Но эти документы считаются временными и не участвуют в бух. учёте, пока в них не будет указана дата проводки.
> Внук © (17.04.06 20:42) [185]
>
> Каким образом вид ключа влияет на количество операторов
> JOIN? Правда, не понимаю. Суррогатный ключ, состоящий из
> одного поля, наоборот упрощает связи. А вот связывать таблицы
> по информационным полям... Брр.
В бухгалтерии есть операция "сторно" -- отмена проведённого документа другим документом. Соответственно, "сторнированный документ" -- это документ, проводка которого отменяется; "сторнирующий документ" -- документ, отменяющий проводку другого документа.
В случае если один документ (сторнирующий) сторнирует другой (сторнируемый), в записи сторнирующего документа сохранится информация о сторнируемом им документе: интересующий нас ключ.
Допустим, нам нужно найти документ, сторнирующий заданный нами документ.
Случай 1. У нас суррогатный ключ. Сначала по заданным номеру и дате документа находим его ключ. После этого уже ищем документ, в поле "документ сторно" которого записан этот ключ. Если эти действия делать одним оператором SELECT, без JOIN не обойтись.
Случай 2. У нас естественный ключ, состоящий из номера и даты проводки. Сразу ищем документ, в полях которого "номер документа сторно" и "дата проводки документа сторно" записаны номер и дата проводки искомого документа. Обошлись без JOIN.
← →
Sergey13 © (2006-04-18 11:31) [206]2[203] Игорь Шевченко © (18.04.06 11:26)
> Я полагаю, что разработчики СУБД допускают использование как естественных, так и искусственных ключей, только и всего.
А я полагаю, что им этот вопрос пофиг. 8-)
С точки зрения физического хранения и обработки СК и ЕК (за что и "отвечают" производители СУБД) нет никакой разницы. Разница в наполнеии структуры смыслом - т.е. епархия программиста прикладника.
← →
Игорь Шевченко © (2006-04-18 11:31) [207]Рекомендую ознакомиться с еще одной точкой зрения -
http://www.ncom.ru/downloads/KeyTaxonomy2005ru.pdf
vuk © (18.04.06 11:26) [204]
Всякий овощ хорош :) Если его правильно есть :)
← →
Игорь Шевченко © (2006-04-18 11:33) [208]Sergey13 © (18.04.06 11:31) [206]
> С точки зрения физического хранения и обработки СК и ЕК
> (за что и "отвечают" производители СУБД) нет никакой разницы.
> Разница в наполнеии структуры смыслом - т.е. епархия программиста
> прикладника.
"Страшно далеки они от народа" (с) :)
← →
Sergey13 © (2006-04-18 11:38) [209]2[208] Игорь Шевченко © (18.04.06 11:33)
> "Страшно далеки они от народа" (с) :)
Более того. Любая СУБД позволяет работать вообще без ключей. 8-)
← →
euru © (2006-04-18 11:39) [210]
> xayam © (17.04.06 23:59) [187]
>
> > euru © (17.04.06 17:42) [179]
>
> Вопрос был не в том испытывает она проблемы по жизни или
> нет, вопрос в способности системы (базы данных) к адаптации
> к изменениям в реальной жизни (ИНН, ISO... ... ...). Если
> Вы используете Естеств.Ключ могу Вас поздравить - гемороя
> не оберетесь (еще раз повторю [30]: а оно Вам надо?), при
> наличии же Сур.Ключа эти изменения сведены к минимуму.
Что Вы говорите? Знали бы разработчики SAP R/3 про геморрой, наверно, несколько раз подумали бы, прежде чем вводить в свою систему естественные ключи.
← →
vuk © (2006-04-18 11:43) [211]to euru © (18.04.06 11:27) [205]:
Решительно не понимаю, чем извлечение СК из записи отличается от извлечения ЕК из записи кроме как количеством извлекаемых полей.
>Случай 1. У нас суррогатный ключ. Сначала по заданным номеру и дате
>документа находим его ключ.
Вот тут ошибочка. При использовании СК документ будем искать не по номеру и дате, а по СК.
← →
Jeer © (2006-04-18 11:48) [212]Игорь Шевченко © (18.04.06 11:31) [207]
http://www.ncom.ru/downloads/KeyTaxonomy2005ru.pdf
С этим я знаком, но там нет противоречий.
Все логично, а далее - опыт разработки и сопровождения делает выбор в пользу СК.
← →
Jeer © (2006-04-18 11:52) [213]vuk © (18.04.06 11:43) [211]
> будем искать не по номеру и дате, а по СК.
Причем быстрее, в общем случае.
← →
Игорь Шевченко © (2006-04-18 11:56) [214]Jeer © (18.04.06 11:48) [212]
> а далее - опыт разработки и сопровождения делает выбор в
> пользу СК.
Чей опыт ?
← →
euru © (2006-04-18 12:15) [215]
> vuk © (18.04.06 11:43) [211]
>
> >Случай 1. У нас суррогатный ключ. Сначала по заданным номеру
> и дате
> >документа находим его ключ.
> Вот тут ошибочка. При использовании СК документ будем искать
> не по номеру и дате, а по СК.
Упс. А откуда пользователь знает суррогатный ключ?
← →
vuk © (2006-04-18 12:24) [216]to euru © (18.04.06 12:15) [215]:
>Упс. А откуда пользователь знает суррогатный ключ?
Я не понял, Вы собираетесь заставлять пользователя дату с номером руками вбивать?
← →
Суслик © (2006-04-18 12:24) [217]2vuk
> Я не понял, Вы собираетесь заставлять пользователя дату
> с номером руками вбивать?
Полагаю, что либо руками, либо выбирать из списка (у нас так)
← →
Jeer © (2006-04-18 12:26) [218]Игорь Шевченко © (18.04.06 11:56) [214]
Личный и коллег.
← →
Anatoly Podgoretsky © (2006-04-18 12:36) [219]Jeer © (18.04.06 12:26) [218]
Программисты они особые
← →
vuk © (2006-04-18 12:41) [220]to Суслик © (18.04.06 12:24) [217]:
>Полагаю, что либо руками, либо выбирать из списка (у нас так)
Ага. Это две разных по сути вещи. Если из списка, то кто никто не мешает иметь СК про который пользователь вообще ничего не знает. А если ручной ввод, так там еще и дополнительные проверки на предмет нелевизны введенных данных нужны будут в любом случае. Так что просто выбрать по условию не получится.
← →
Игорь Шевченко © (2006-04-18 12:41) [221]Jeer © (18.04.06 12:26) [218]
Личный опыт, он есть у каждого. Например, мой опыт говорит мне, что ничего страшного в естественных ключах нету. Опыт конечно аргумент хороший, но он у каждого свой :)
← →
Jeer © (2006-04-18 12:43) [222]Игорь Шевченко © (18.04.06 12:41) [221]
Есть еще общая практика, основанная на личном опыте каждого.
Она здесь наблюдаема.
← →
Игорь Шевченко © (2006-04-18 12:44) [223]Jeer © (18.04.06 12:43) [222]
Прежде чем говорить об общей практике, неплохо бы выяснить круг задач, к которому эта практика относится. Пока я вижу, что у большинства в этой ветке практика связана со всякого рода бухгалтерией.
← →
Jeer © (2006-04-18 12:47) [224]Игорь Шевченко © (18.04.06 12:44) [223]
Для задач СУБД это не принципиальный момент - прикладное содержание.
← →
Игорь Шевченко © (2006-04-18 12:51) [225]Jeer © (18.04.06 12:47) [224]
> Для задач СУБД это не принципиальный момент - прикладное
> содержание.
Весьма спорный тезис.
← →
DiamondShark © (2006-04-18 13:08) [226]А по-моему, по-барабану какой ключ -- естественный или суррогатный.
Лишь бы его значения были атомарными и компактными.
← →
euru © (2006-04-18 13:47) [227]
> vuk © (18.04.06 12:24) [216]
>
> to euru © (18.04.06 12:15) [215]:
> >Упс. А откуда пользователь знает суррогатный ключ?
> Я не понял, Вы собираетесь заставлять пользователя дату
> с номером руками вбивать?
А Вы, я так понимаю, вместо номера и даты документа предлагаете ему какой-то код вводить.
> vuk © (18.04.06 12:41) [220]
>
> to Суслик © (18.04.06 12:24) [217]:
> >Полагаю, что либо руками, либо выбирать из списка (у нас
> так)
> Ага. Это две разных по сути вещи. Если из списка, то кто
> никто не мешает иметь СК про который пользователь вообще
> ничего не знает. А если ручной ввод, так там еще и дополнительные
> проверки на предмет нелевизны введенных данных нужны будут
> в любом случае. Так что просто выбрать по условию не получится.
Наверно, для формирования списка сторнированных документов нужно будет знать хотя бы их дату проводки, чтобы ограничить этот список до разумных пределов. Получается, что JOIN переместится в процедуру формирования этого списка.
← →
Внук © (2006-04-18 14:51) [228]>>euru © (18.04.06 13:47)
Понятно, спасибо за пример. Но в данном случае JOIN ничего не стОит базе данных, поскольку идет обрашение к одной записи из связанной таблицы по значению ПК - практически мгновенно.
Я все читаю примеры, где первичный ключ может использоваться, но не вижу примеров, где он дает хотя бы одно реальное преимущество. Вот ведь в чем незадача. А главное - те гениальные слова Булгакова о том, что "не то страшно, что человек смертен, а то, что иногда он внезапно смертен" - очень хорошо подходят к ПК. Был он, а потом "концепция изменилась". Здравствуй, геморрой. Насчет R3 - так они заставляют пользователей ожиться под систему, а не наоборот - я писал здесь про коробочный продукт.
← →
Внук © (2006-04-18 14:52) [229]В смысле - я как раз про это писал, когда вел речь про коробочный продукт.
← →
Суслик © (2006-04-18 15:24) [230]
> [229] Внук © (18.04.06 14:52)
> В смысле - я как раз про это писал, когда вел речь про коробочный
> продукт.
Как я тебя понимаю...
Жутко хочется писать именно коробочный вариант - чтобы пользователи покупали и прилаживались. Но вот не хотят они что-то. Приходится писать под заказчика со всеми вытекающими, например, часто модфицируемыми требованиями. В этом случае имхо СК лучше.
← →
Внук © (2006-04-18 15:32) [231]>>Суслик © (18.04.06 15:24) [230]
Да в этом и разница мнений. Устроились хорошо, пишут по-науке, буржуи, жируют :)) Теоретики.
← →
Игорь Шевченко © (2006-04-18 15:35) [232]Внук © (18.04.06 15:32) [231]
> пишут по-науке, буржуи, жируют
"Завидовать дурно" (с) Попытка к бегству
← →
Внук © (2006-04-18 15:39) [233]>>Игорь Шевченко © (18.04.06 15:35) [232]
А что поделать :)
← →
euru © (2006-04-18 15:50) [234]
> Внук © (18.04.06 14:51) [228]
>
> >>euru © (18.04.06 13:47)
> Понятно, спасибо за пример. Но в данном случае JOIN ничего
> не стОит базе данных, поскольку идет обрашение к одной записи
> из связанной таблицы по значению ПК - практически мгновенно.
Ну так это же был пример. Вместо одного документа может быть список документов. Более того, связь между документами может быть сложнее: цепочка может состоять не из 2-х документов, а из 3-4-х, а на каждый из этих документов могут быть наложены свои дополнительные ограничения.
> Насчет R3 - так они заставляют пользователей
> ожиться под систему, а не наоборот - я писал здесь про коробочный
> продукт.
SAP R/3 позволяет с нуля написать любую функциональность. Для этого в нём имеется встроенный объектно-ориентированный язык программирования (он, конечно, выглядит несколько необычно для привыкших к Delphi, C++, но в последних версиях можно писать и на Java). Только вот имеет ли смысл это делать, если уже имеются наработанные и проверенные во многих странах и на многих предприятиях решения?
← →
Суслик © (2006-04-18 16:45) [235]
> Да в этом и разница мнений. Устроились хорошо, пишут по-науке,
> буржуи, жируют :)) Теоретики.
или не пишут :)
или всего не говорят :)
или еще что-то :)
хотя, почему нет. Вполне могу допустить, что есть узкоспециализированные области в которых коробочное решение "работает".
← →
Игорь Шевченко © (2006-04-18 17:04) [236]Суслик © (18.04.06 16:45) [235]
> Вполне могу допустить, что есть узкоспециализированные области
> в которых коробочное решение "работает".
А при большом желании можно допустить, что границы области, где коробочное решение работает (без кавычек), несколько шире, чем ты себе представляешь.
← →
Суслик © (2006-04-18 17:17) [237]
> [236] Игорь Шевченко © (18.04.06 17:04)
> А при большом желании можно допустить, что границы области,
> где коробочное решение работает (без кавычек), несколько
> шире, чем ты себе представляешь.
А вот у меня несколько иная информация:
1. 1с
2. r3
3. скала
4. аксапта
5. баан
6. системы бюждетирования (несколько у заказчиков стоят).
При том есть системы в виде коробочных решений:
1. windows2000server :)
2. windowsxp
3. Системы авторизации (ключики, флешки).
4. есть еще - но это то, что вспомнил.
Я полагаю, что о "коробочности" стоит говорить в определенном контексте задачи.
← →
Игорь Шевченко © (2006-04-18 17:19) [238]Суслик © (18.04.06 17:17) [237]
> Я полагаю, что о "коробочности" стоит говорить в определенном
> контексте задачи
Кто бы спорил. Точно так же, как и о применимости естественных и суррогатных ключей.
← →
Jeer © (2006-04-18 17:44) [239]Игорь Шевченко © (18.04.06 17:19) [238]
К вопросу о производительности систем с СК и ЕК.
Я тот (см.выше) тестовый примерчик не поленился и проверил, хотя, если честно - лет 7-6 назад делал по заказу одной уважаемой орг-и тестирование нескольких движков и СУБД в сравнении др с др. (MS Jet, IB, Posgress, DBISAM, Paradox и др.)
Тогда я получил вполне внятный ответ на свои вопросы.
Сейчас ответ не изменился.
СК имеют преимущество в выборке.
Тест проводился на MS OLE ODBC и формате access.
В среднем время выборки на СК не зависит от сочетаний поисковых полей
и составляет на объеме 30 тыс записей 7 ms
Для ЕК время выборки зависит от порядка полей в PK (ну разумеется :))) и составляет от 7 до 70 ms.
В наихудшем случае при выборке всего объема время одинаково - 280 ms
Разумется, это всего лишь маленький и не обобщающий пример, но - пример.
← →
Jeer © (2006-04-18 17:47) [240]P.S.
С увеличением числа записей инспектируемой таблицы ситуация будет улучшаться для СК.
← →
vuk © (2006-04-18 17:53) [241]to euru © (18.04.06 13:47) :
> А Вы, я так понимаю, вместо номера и даты документа предлагаете
> ему какой-то код вводить.
Если нужно именно дату и номер, то надо вводить дату и номер, но дело в том, что обычно интерфейс проектируется так, чтобу вообще это дело свести к минимуму. То есть есть список документов на дату, где можно посмотреть любой документ, найти по номеру в списке и т.п. И ничего не надо вводить руками.
> Наверно, для формирования списка сторнированных документов
> нужно будет знать хотя бы их дату проводки, чтобы ограничить
> этот список до разумных пределов. Получается, что JOIN переместится
> в процедуру формирования этого списка.
Если это нужно, то да, в процедуру формирования списка. Вопрос в том, нужно ли это.
А вообще, если главным условием при проектировании делать минимизацию числа Join-ов, то можно вообще куда-нибудь не туда прийти в результате.
← →
Jeer © (2006-04-18 17:55) [242]vuk © (18.04.06 17:53) [241]
> И ничего не надо вводить руками.
Верно. а если и вводится, то дополнительный поиск по существующим сущностям ограничит любознательность пользователя.
← →
Игорь Шевченко © (2006-04-18 18:05) [243]Jeer © (18.04.06 17:44) [239]
Оно конечно интересно, но отличается тем, что в реальной жизни обычно скорость выборки не является самым существенным критерием, тем более, что железо имеет свойство, согласно закону Мура, каждые 18 месяцев удваивать производительность. Для пущей наглядности неплохо бы показать созданные таблицы для обоих вариантов тестирования, запросы на выборку и их планы, и, собственно, статистику выборки. Разумеется, перед каждой выборкой должен быть очищен кэш сервера базы данных.
← →
Jeer © (2006-04-18 18:14) [244]Игорь Шевченко © (18.04.06 18:05) [243]
> существенным критерием,
является все , за что необходимо бороться для Заказчика, а иногда и для повышения своего уровня.
> Для пущей наглядности..
Можно, но не нужно:)
Для локального варианта access не так много надо усилий.
А пример таблиц я приводил выше.
Выборки идут по любому сочетанию трех полей (фамилия, имя, отчество)
Индексы есть.
← →
Внук © (2006-04-18 19:29) [245]>>Игорь Шевченко © (18.04.06 18:05) [243]
>>в реальной жизни обычно скорость выборки не является самым существенным критерием, тем более, что железо имеет свойство, согласно закону Мура, каждые 18 месяцев удваивать производительность
А "лишнее" поле суррогатного ключа, конечно, является непозволительным расточительством ресурсов :)))
← →
Игорь Шевченко © (2006-04-18 21:53) [246]Внук © (18.04.06 19:29) [245]
> А "лишнее" поле суррогатного ключа, конечно, является непозволительным
> расточительством ресурсов :)))
>
Ты знаешь, да. Только не с точки зрения хранения, а с точки зрения программирования. Я все-таки возвращусь к своей мысли - всякий овощ приносит пользу. И настаивать только на одном из способов не вижу смысла.
Jeer © (18.04.06 18:14) [244]
> Можно, но не нужно:)
Тогда твои миллисекунды тоже ничего не значат :)
← →
xayam © (2006-04-18 22:59) [247]
> Игорь Шевченко ©
> Я бы не сказал, что они такие уж редкие. Почему, интересно,
> авторы книжек по СУБД не рекомендуют, все как один, использовать
> исключительно синтетические ключи ? Они в другом мире живут?
Этот мир называется база данных
> А я еще раз могу повторить про овощи. Про преимущества и
> недостатки уже 195 постов обсуждаем. У естественных ключей
> преимущество в первую очередь в простоте программирования,
> а как ты сам понимаешь, чем проще программировать, тем
> меньше ошибок и тем легче сопровождать систему.
А раз ты это понимаешь, почему же настаиваешь на использовании ЕК, разве что ты и не собираешься делать никакую базу. И заказчики сюда хорошо вписываюся))...
> Прежде чем говорить об общей практике, неплохо бы выяснить
> круг задач, к которому эта практика относится. Пока я вижу,
> что у большинства в этой ветке практика связана со всякого
> рода бухгалтерией.
О тебе далеко даже до практики, с теорией бы разобраться, что такое нормализация, зачем нужен первичный ключ, что такое индекс и как на него влияет присутствие ЕК, ... можно долго продолжать
> Тогда твои миллисекунды тоже ничего не значат :)
это твои аргументы?
> xayam © (17.04.06 23:59) [187]
> > Вопрос был не в том испытывает она проблемы по жизни или
> > нет, вопрос в способности системы (базы данных) к адаптации
> > к изменениям в реальной жизни
> Примеры адаптации в студию. Без примеров твои слова пустой звон.
ага щас
← →
xayam © (2006-04-18 23:03) [248]
> DiamondShark © (18.04.06 13:08) [226]
> А по-моему, по-барабану какой ключ -- естественный или суррогатный.
>
> Лишь бы его значения были атомарными и компактными.
тебе знакомо слово "нормализация", мало того что он атомарный он не должен зависеть...
← →
xayam © (2006-04-18 23:03) [249]
> Jeer © [239] [240]
+1
← →
Игорь Шевченко © (2006-04-18 23:40) [250]xayam © (18.04.06 22:59) [247]
> О тебе далеко даже до практики, с теорией бы разобраться,
> что такое нормализация, зачем нужен первичный ключ, что
> такое индекс и как на него влияет присутствие ЕК, ... можно
> долго продолжать
Расскажи, я с удовольствием послушаю.
> А раз ты это понимаешь, почему же настаиваешь на использовании
> ЕК, разве что ты и не собираешься делать никакую базу. И
> заказчики сюда хорошо вписываюся))...
Дорогой друг, приводи пожалуйста разумные аргументы при ведении дискусии. Детский сад находится в другом месте и большинство участников из него уже выросли.
> это твои аргументы?
Дорогой друг, изучи пожалуйста методику проведения тестов, а потом высказывайся.
xayam © (18.04.06 23:03) [248]
> тебе знакомо слово "нормализация", мало того что он атомарный
> он не должен зависеть...
С этого места подробнее - какое отношение естественные и суррогатные ключи имеют к нормализации ?
← →
xayam © (2006-04-19 00:01) [251]
> Игорь Шевченко © (18.04.06 23:40) [250]
> Расскажи, я с удовольствием послушаю.
извини но честно говорю не люблю болтать
> разумные аргументы
их столько было выше, они же тебе не нужны (и отмазки такие интересные - зачем писать такие проги...или используй триггеры...)
> изучи пожалуйста методику проведения тестов
обязательно
> какое отношение естественные и суррогатные ключи имеют к
> нормализации ?
если точнее, то "ключи" и "нормализация". Или у них тоже ничего общего?
← →
Игорь Шевченко © (2006-04-19 00:10) [252]xayam © (19.04.06 00:01) [251]
> извини но честно говорю не люблю болтать
А зачем тогда ссылаешься на то, о чем не хочешь рассказывать, хотя бы тезисно ?
> их столько было выше, они же тебе не нужны
А у меня и свои аргументы есть, как ни странно. Я их ветке приводил не один раз. Могу для тебя персонально привести еще раз общую мысль - любые ключи, и естественные и суррогатные имеют право на существования в таблицах базы данных и их применение определяется не религиозными догмами, а исключительно решаемыми задачами и предметной областью.
Есть еще желание продолжить дискуссию - милости просим.
Но прежде чем дискутировать, чтобы не повторяться, прочитай пожалуйся статью по ссылке, приведенной выше, называется Keytaxonomy2005.
← →
xayam © (2006-04-19 00:31) [253]
> и естественные и суррогатные имеют право на существования
имеют, никто не спорит, вопрос как раз в простоте использования, поддержки, безопасности (что еще было)
> а исключительно решаемыми задачами и предметной областью
да куда ни глянь естественные ключи создают только проблемы и ничего не решают. Как это говорят, разделяй и властвуй.
Да хоть на примере твоих стран, они же не вечны. А если разделишь свою базу на простые сущности, отраж.реальн.объект (нормализуешь), то все это только упрощает любые изменения во внеш.мире, которые должны отобразиться на базе.
← →
Игорь Шевченко © (2006-04-19 00:42) [254]xayam © (19.04.06 00:31) [253]
> вопрос как раз в простоте использования, поддержки, безопасности
Все зависит от задачи. А то, что проще - я думаю, даже не надо теоремы доказывать.
> да куда ни глянь естественные ключи создают только проблемы
> и ничего не решают
А куда ты глядишь, если не секрет ?
> Да хоть на примере твоих стран, они же не вечны.
Мои страны как раз вечны в рамках стандарта ISO. Как ты понимаешь, даже при прекращении существования страны ее код никакой другой стране не присваивается. Кроме того, если страна прекратило свое существование, то прекратили сове существование и все связанные с ней атрибуты, как то, ее столица, население и тому подобные качественные и количественные характеристики. Так что не вижу причины.
> А если разделишь свою базу на простые сущности, отраж.реальн.
> объект (нормализуешь),
Вот страна и есть реальный объект, куда ее дальше разделять на простые сущности ?
Другой такой же реальный обхект - это город, тоже никуда не разделяется вроде...
Ты все-таки статью почитай, оно интересно.
> все это только упрощает любые изменения во внеш.мире, которые
> должны отобразиться на базе
Ты, чтобы не быть голословным, пример приведи. Хотя бы со странами, раз уж за них зацепились.
← →
xayam © (2006-04-19 00:55) [255]
> А куда ты глядишь, если не секрет ?
секрет))
> Мои страны как раз вечны в рамках стандарта ISO
С какого перепугу, стандарты приходят и уходят, а мы все на форуме
> Как ты понимаешь, даже при прекращении существования страны
> ее код никакой другой стране не присваивается
серьезно? Кто сказал, фамилия имя отчество. И ты ему поверил?
> Кроме того, если страна прекратило свое существование,
> то прекратили сове существование и все связанные с ней атрибуты,
> как то, ее столица, население и тому подобные качественные
> и количественные характеристики. Так что не вижу причины.
невнимательно читал, приводили хороший пример с номерами от машины. А что если стандарта не будет, то не будет и страны? Стандарт это только один из атрибутов.
> Ты, чтобы не быть голословным, пример приведи. Хотя бы со
> странами, раз уж за них зацепились.
хочу быть голословным (пример выше)
← →
Игорь Шевченко © (2006-04-19 01:11) [256]xayam © (19.04.06 00:55) [255]
> С какого перепугу, стандарты приходят и уходят, а мы все
> на форуме
Дорогой друг, ты вообще в курсе, зачем вводятся стандарты ? Я тебе намекну - стандарты вводятся для того, чтобы сформировать общее одинаковое представление о какой-либо сущности. Так вот, в связи с этим, стандарты ISO в части кодировок стран и прочей географии служат для того, чтобы сформировать общее представление, от том, что под кодом UA подразумевается страна Украина, а не Острова зеленого мыса. То есть, это тоже близко к суррогатному ключу, в конце концов, для стран все ключи будут суррогатными, но этот ключ, который однозначно определяет страну во всех базах данных, в которых принято использовать этот стандарт. И при обмене данными с китайской базой, например, все ID идут лесом и надолго, потому что ID однозначно будет идентифицировать сущность только в конкретной базе данных. Название тоже идет лесом, потому что в китайской базе оно, соответсвенно, китайское, а в украинской, сам понимаешь, украинское. И поэтому, для однозначной идентификации используется именно ОБЩИЙ СТАНДАРТНЫЙ ключ.
> серьезно? Кто сказал, фамилия имя отчество. И ты ему поверил?
>
Поверил. И тебе советую поверить, он еще ни разу не врал. Фамилия имя отчество - International Standard Organization, немного непривычно, но это только вначале.
> невнимательно читал, приводили хороший пример с номерами
> от машины. А что если стандарта не будет, то не будет и
> страны? Стандарт это только один из атрибутов.
С номерами та же байда, только стандарт более узкий. Если стандарта не будет, то ты страну не опишешь (и машину тоже не опишешь). Даже название страны тоже является стандартом, как ни странно.
← →
xayam © (2006-04-19 01:24) [257]
> чтобы сформировать общее одинаковое представление о какой-
> либо сущности
у меня не сформировалось, может у кого тоже
> International Standard Organization
я вообще русский и когда меня пугают фразами из трех слов да еще на англицком, то я за себя не отвечаю))
> Если стандарта не будет, то ты страну не опишешь
Запросто - Россия
> Даже название страны тоже является стандартом, как ни странно
а я о чем вчера СССР, сегодня РФ. Как поменяли? Это же стандарт, не сформировалось видно...и у них тоже
← →
Игорь Шевченко © (2006-04-19 10:12) [258]xayam © (19.04.06 01:24) [257]
> у меня не сформировалось
Видишь ли, организация ISO не ставит своей целью сформировать именно твое представление.
> Запросто - Россия
Объясни это говорящим на других языках. По крайней мере у тебя будет чем время занять.
> а я о чем вчера СССР, сегодня РФ. Как поменяли?
Ничего не меняли. СССР было SU, Россия - RU. Никаких проблем для того, чтобы отличить, нету.
← →
Jeer © (2006-04-19 10:21) [259]Игорь Шевченко © (18.04.06 21:53) [246]
> Тогда твои миллисекунды тоже ничего не значат :)
Миллисекунды всегда значат больше, чем чье-либо особое мнение.
← →
Игорь Шевченко © (2006-04-19 10:30) [260]Jeer © (19.04.06 10:21) [259]
> Миллисекунды всегда значат больше, чем чье-либо особое мнение.
В том случае, если они воспроизводимы, не так ли ?
← →
Jeer © (2006-04-19 10:33) [261]разумеется, иначе это лженаука:))
Но мне кажется, что лично тебе не интересно ковыряться с такими "мелочами",
т.к. ответ изначално тебе известен.
← →
Игорь Шевченко © (2006-04-19 10:53) [262]Jeer © (19.04.06 10:33) [261]
Нет, не в этом дело. Я не считаю, что естественные ключи есть зло, подлежащее выкорчевыванию. В программах для меня важна в первую очередь простота, во второую очередь сопровождабельность и лишь в третью очередь - производительность.
← →
Lamer@fools.ua © (2006-04-19 10:58) [263]>В программах для меня важна в первую очередь простота, во второую очередь сопровождабельность...
"Доктор, у меня такое впечатление, что меня все игнорируют" ©
На [200] можно узнать ответ?
← →
Sergey13 © (2006-04-19 11:00) [264]2[262] Игорь Шевченко © (19.04.06 10:53)
>В программах для меня важна в первую очередь простота, во второую очередь сопровождабельность и лишь в третью очередь - производительность.
Интересная позиция. Другими словами - лишь бы мне было хорошо, а юзер нехай загнется. 8-)
← →
Jeer © (2006-04-19 11:10) [265]
> В программах для меня
Может в этом все дело ?
Ограниченный спектр ПО ?
Для меня важными остаются приоритеты:
- скорость разработки (без унификации это сложно, а если Заказчик на ходу меняет предпочтение в СУБД и такое бывает ?);
- удобство пользования (интерфейс и производительность);
- удобство сопровождения (чаще всего это вынужденные изменения во внешней информационной среде, а это уже доработка);
← →
Игорь Шевченко © (2006-04-19 11:14) [266]Lamer@fools.ua © (18.04.06 11:07)
> Почему, когда я пишу JOIN в запросе, я должен вспоминать,
> по какому полю (или, упаси Аллах, полям) мне нужно соединять
> таблицы в ON?
А почему ты должен вспоминать, какие таблицы тебе надо соединять или какие из них поля надо выбирать и по каким критериям ограничивать выборку ?
← →
Игорь Шевченко © (2006-04-19 11:20) [267]Jeer © (19.04.06 11:10) [265]
> Ограниченный спектр ПО ?
Разумеется, ограниченный. А как иначе ? Необъятное не обнимешь, как ни старайся.
> - скорость разработки (без унификации это сложно, а если
> Заказчик на ходу меняет предпочтение в СУБД и такое бывает
> ?);
Сергей, дело в том, что если заказчик меняет предпочтение в СУБД, то в моем случае у меня одним заказчиком автоматически становится меньше. Потому что переделывать всю серверную часть (а это не только таблицы), нанимать специалистов со знанием предпочтенной заказчиком СУБД, просто невыгодно экономически.
> - удобство пользования (интерфейс и производительность);
Это со структурой базы, как ты сам понимаешь, не связано.
> - удобство сопровождения (чаще всего это вынужденные изменения
> во внешней информационной среде, а это уже доработка);
Вот с этим согласен. Мне удобнее сопровождать, когда в программе не введено лишних сущностей. В угоду унификации или еще каким религиозным соображениям.
← →
Lamer@fools.ua © (2006-04-19 11:22) [268]>>Игорь Шевченко © (19.04.06 11:14) [266]
>какие таблицы тебе надо соединять или какие из них поля надо выбирать и по каким критериям ограничивать выборку
Ну это мне придётся помнить в любом случае, не так ли?
← →
Игорь Шевченко © (2006-04-19 11:26) [269]Lamer@fools.ua © (19.04.06 11:22) [268]
> Ну это мне придётся помнить в любом случае, не так ли?
Ну да, конечно. А поля во всех таблицах для всех связок у тебя одинаково называется во избежание склероза ? :)
← →
Jeer © (2006-04-19 11:30) [270]
> то в моем случае у меня одним заказчиком автоматически становится
> меньше.
Значит это будет мой Заказчик, т.к мне все равно - какая СУБД.:))
> Это со структурой базы, как ты сам понимаешь, не связано.
Производительность связана и со структурой и с движком.
> когда в программе не введено лишних сущностей.
Отвлеченный пример:
Закладки в книге не мешают читать, а позволяют быстрее открывать на нужном месте, хотя тоже - лишняя сущность и самой книге - как пятое колесо.
P.S.
Я понимаю, ты резко занятый человек, но вот возьми мой примерчик и проверь и нам будет интересно - совпадение или нет результатов в разных географических регионах.
← →
Lamer@fools.ua © (2006-04-19 11:34) [271]>А поля во всех таблицах для всех связок у тебя одинаково называется во избежание склероза ? :)
Возможно Вы поставите ещё мильон смайлов, но вообще-то да. Точнее не одинаково, а единообразно.CREATE TABLE [dbo].[tbe_Address] (
[Id] [int] IDENTITY (1, 1) NOT NULL PRIMARY KEY,
[AddressLines] [ntext] NOT NULL,
[City] [nvarchar] (128) NOT NULL,
[CountryId] [int] NULL,
[ZipCode] [nvarchar] (128) NOT NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
CREATE TABLE [dbo].[tbe_Contact] (
[Id] [int] IDENTITY (1, 1) NOT NULL PRIMARY KEY,
[AddressId] [int] NOT NULL,
[EMail] [nvarchar] (128) NOT NULL,
[FaxNumber] [nvarchar] (128) NOT NULL,
[MobilePhoneNumber] [nvarchar] (128) NOT NULL,
[Name] [nvarchar] (128) NOT NULL,
[PhoneNumber] [nvarchar] (128) NOT NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[tbe_Address] ADD
CONSTRAINT [FK_tbe_Address_CountryId_tbe_Country_Id] FOREIGN KEY
(
[CountryId]
) REFERENCES [dbo].[tbe_Country] (
[Id]
)
GO
ALTER TABLE [dbo].[tbe_Contact] ADD
CONSTRAINT [FK_tbe_Contact_AddressId_tbe_Address_Id] FOREIGN KEY
(
[AddressId]
) REFERENCES [dbo].[tbe_Address] (
[Id]
)
GO
← →
Внук © (2006-04-19 11:35) [272]>>Игорь Шевченко © (19.04.06 11:26) [269]
>>А поля во всех таблицах для всех связок у тебя одинаково называется во избежание склероза ? :)
Само собой. Имя_таблицы+ID. Я уже намекал на построение скрипта базы Case-средствами. Если это религия, то ... Будешь обзываться - я отвечу адекватно :)
← →
Lamer@fools.ua © (2006-04-19 11:36) [273]OFFTOPIC:
Не понял. Почему в [271] пробелы "съелись"?
← →
Игорь Шевченко © (2006-04-19 11:37) [274]Jeer © (19.04.06 11:30) [270]
> Значит это будет мой Заказчик, т.к мне все равно - какая
> СУБД.:))
Это вряд ли :) Среди списка своих конкурентов я тебя не наблюдаю :)
> Производительность связана и со структурой и с движком.
Только отчасти. Абстрактная производительность она чаще всего не играет важной роли. Играет роль время реакции системы.
> Я понимаю, ты резко занятый человек, но вот возьми мой примерчик
> и проверь и нам будет интересно - совпадение или нет результатов
> в разных географических регионах.
А я бы с удовольствием, если ты скрипт напишешь. Только Access и MSSQL у меня нету. Есть Firebird (Interbase)
← →
Jeer © (2006-04-19 11:40) [275]
> Играет роль время реакции системы.
В фундаменте реакции системы лежат производительности ее составляющих.
> скрипт напишешь.
ок
← →
Jeer © (2006-04-19 11:41) [276]Внук © (19.04.06 11:35) [272]
> Само собой. Имя_таблицы+ID.
А бывает иначе ? :)))
← →
Danilka © (2006-04-19 11:44) [277][276] Jeer © (19.04.06 11:41)
> А бывает иначе ? :)))
Ага :)
У меня просто имя таблицы :)
← →
Sergey Masloff (2006-04-19 11:45) [278]Jeer © (19.04.06 11:41) [276]
>А бывает иначе ? :)))
Бывает. У меня ISN (от Internal System Number)
← →
Sergey Masloff (2006-04-19 11:46) [279]к Sergey Masloff (19.04.06 11:45) [278]
Ну в смысле Имя_таблицы+ISN
← →
Jeer © (2006-04-19 11:47) [280]Sergey Masloff (19.04.06 11:46) [279]
Я о конкатенации:)
← →
Игорь Шевченко © (2006-04-19 11:49) [281]Lamer@fools.ua © (19.04.06 11:34) [271]
Ну тебя же не затрудняет запоминать слова типа AddressId ? :) Точно также, как меня не затрудняет запоминать слова CityCode
← →
Jeer © (2006-04-19 11:55) [282]Sergey Masloff (19.04.06 11:46) [279]
Владимир Котляревский
ООП в СУБД
рекомендует GUID в пределах базы, что не лишено смысла.
← →
Jeer © (2006-04-19 11:57) [283]Ссылка и там же есть по поводу ЕК нелестности.
http://www.ibase.ru/devinfo/oop_rdbms.htm
← →
Игорь Шевченко © (2006-04-19 12:00) [284]Jeer © (19.04.06 11:55) [282]
> рекомендует GUID в пределах базы, что не лишено смысла.
"В последнее время наметилась одна очень нехорошая тенденция: многие разработчики совершенно безответственно относятся к тому, как их приложения используют ресурсы. Да, я понимаю все аргументы, связанные с быстрым ростом производительности аппаратуры и стоимости оптимизации приложений. Кроме того, многие авторитеты последовательно призывают к своевременному освобождению ресурсов, занятых приложением, а также к минимизации ресурсов, используемых одновременно.
Я терпеливо следил за дискуссиями на эту тему, пока один ужасающий факт не привлек мое внимание.
Дело в том, что, когда речь заходит о ресурсах в применении к программированию, обычно подразумеваются локальные ресурсы компьютера, на котором выполняются приложения. И, в большинстве случаев, это восполнимые ресурсы, которые еще и занимаются только на время работы приложения.
Но, как я недавно понял, существует один важный ресурс, который, во-первых, является глобальным, а во-вторых, совершенно невосполнимым!
Я говорю о глобально уникальных идентификаторах, или UUID (также известных как GUID, CLSID, IID и др.). Как следует из документации, каждое обращение к функции WinAPI UuidCreate возвращает уникальный идентификатор! Более того, этот способ настоятельно рекомендуется к применению всякий раз, как в приложении нужно что-либо уникальное. Но ведь очевидно, что все эти идентификаторы берутся из конечного набора! И каждый вызов UuidCreate уменьшает, таким образом, количество идентификаторов, доступных всем приложениям! Стоит также заметить, что не существует никакого способа сдать использованный идентификатор обратно, когда он больше не нужен.
Самое ужасное в том, что исчерпание этого ресурса мгновенно парализует работу всех приложений, которые его используют. К несчастью, их список включает не только поделки, слепленные на коленке полуграмотными подростками. Такие серьезные продукты, как MS SQL Server, используют GUID для идентификации транзакций. На их основе работают многие сервисы, стабильность которых определяет комфорт, а иногда и жизнь людей.
Я не против использования этой технологии вообще. Но многие программисты игнорируют те строки документации по функции CoCreateGuid, в которых рекомендуется использовать ее для получения постоянных идентификаторов в распределенной вычислительной среде:
Use the CoCreateGuid function when you need an absolutely unique number that you will use as a persistent identifier in a distributed environment.
Я вижу несколько решений данной проблемы. Скорее всего, идеально было бы сделать функцию UuidCreate платной. Даже цены в 1 доллар за 1000 GUID было бы достаточно для того, чтобы разработчики задумались о количестве идентификаторов, потребляемых их приложениями. Но пока этот сервис остается бесплатным, я призываю программистов всего мира прекратить безответственную практику использования глобально уникальных идентификаторов для короткоживущих объектов, а также для настольных приложений, в которых можно использовать альтернативные методики получения уникальных идентификаторов (например, последовательности целых чисел).
Я также собираюсь обратиться к компании Microsoft c требованием реализовать функцию UuidDestroy, которая позволит возвращать обратно ставшие ненужными уникальные идентификаторы (я даже боюсь представить это бесчисленное множество уже безвозвратно утерянных GUID!).
Если вы поддерживаете эту акцию, то напишите, пожалуйста, письмо в штаб-квартиру Microsoft в Редмонде по следующему адресу:
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
USA"
http://rsdn.ru/article/mag/200301/GUIDEcology.xml
← →
Jeer © (2006-04-19 12:07) [285]Игорь Шевченко © (19.04.06 12:00) [284]
Я и Котляревский не об этом, а об UID (number) - уникальном в пределах базы.
А вообще - посмеялся:)
← →
Danilka © (2006-04-19 12:10) [286][284] Игорь Шевченко © (19.04.06 12:00)
:))
Забавно.
Ну, вообще-то, Jeer немного ошибся, в [282], судя по хорошей ссылке в след. посте Владимир Котляревский рекомендует не именно GUID, просто уникальный ID в пределах базы, который, судя по его скриптам, имеет тип Integer.
← →
Danilka © (2006-04-19 12:11) [287][285] Jeer © (19.04.06 12:07)
Упс, опоздал. :)
← →
Игорь Шевченко © (2006-04-19 12:16) [288]Jeer © (19.04.06 12:07) [285]
> Я и Котляревский не об этом, а об UID (number) - уникальном
> в пределах базы.
Это оно все хорошо, в пределах базы (кстати, базы или таблицы?), но как быть, если необходимо одну и ту же сущность понимать одинаково во многих базах ?
← →
Jeer © (2006-04-19 12:22) [289]..базы с таблицами
> если необходимо одну и ту же сущность понимать одинаково
> во многих базах
и странах мира:)))
← →
Игорь Шевченко © (2006-04-19 12:26) [290]Jeer © (19.04.06 12:22) [289]
> и странах мира:)))
Кстати да, я в 256 посте написал.
← →
Jeer © (2006-04-19 12:29) [291]Игорь Шевченко © (19.04.06 12:26) [290]
Ну Иванова в Японии тоже не знают:)
Надо его вводить в международный стандарт, чтобы никто не ошибся.
← →
DiamondShark © (2006-04-19 12:34) [292]
> Игорь Шевченко © (19.04.06 12:00) [284]
GUID -- это 128 битное число.
Количество комбинаций 2^128 =~ 3e38
Если считать, что на земле живёт семь миллиардов людей, и у каждого из них есть компьютер, который круглые сутки генерирует 1000 GUID в секунду, то "кончатся" гуиды примерно через 1.5e18 лет.
Подробности для любознательных:
Время существования видимой вселенной оценивается по современным космологическим прдеставлениям в 1.5e10..2.5e10 лет.
← →
Игорь Шевченко © (2006-04-19 12:36) [293]Jeer © (19.04.06 12:29) [291]
> Ну Иванова в Японии тоже не знают:)
И что с того ?
← →
DiamondShark © (2006-04-19 12:41) [294]Кстати, китайцы успешно производят и реализуют крупные партии сетевых адаптеров с одинаковыми MAC-адресами, так что все сгенерированные в мире GUIDы являются таковыми весьма условно :)
Да и вообще, IP-адреса кончатся быстрее гуидов. Так что когда развитие различных distributed environment-ов достигнет своего тупика, оставшихся гуидов как раз хватит на все первичные ключи.
:)))
← →
Lamer@fools.ua © (2006-04-19 13:32) [295]>>Игорь Шевченко © (19.04.06 11:49) [281]
>Ну тебя же не затрудняет запоминать слова типа AddressId ? :) Точно также, как меня не затрудняет запоминать слова CityCode
Ну дык мне и запоминать-то не надо. Если объединяю таблицу tbe_Contact с таблицей tbe_Address, то сразу знаю, что в ON будет AddressID. То есть мне нужно запомнить только способ образования поля-ВК, а не само наименование поля (или что ещё хуже — наименования нескольких полей). И этот способ един в пределах всей БД.
← →
Игорь Шевченко © (2006-04-19 13:37) [296]Lamer@fools.ua © (19.04.06 13:32) [295]
Ради Аллаха, можно придерживаться любых правил именования, но какое отношение эти правила имеют к решаемым задачам ? Или ты не будешь решать задачи, в которых структура базы данных не будет соответствовать канонам имен ?
← →
DiamondShark © (2006-04-19 13:40) [297]А вот в SQL Sybase ASA были замечательные конструкции: KEY JOIN и NATURAL JOIN.
KEY JOIN связывала таблицы по описанным в схеме FK, а NATURAL JOIN -- по одноимённым полям таблиц.
:)
← →
Lamer@fools.ua © (2006-04-19 14:37) [298]>>Игорь Шевченко © (19.04.06 13:37) [296]
>Или ты не будешь решать задачи, в которых структура базы данных не будет соответствовать канонам имен ?
Почему не буду? Буду. Путём рефакторинга и приведения к канонам :-))
← →
Игорь Шевченко © (2006-04-19 14:54) [299]Lamer@fools.ua © (19.04.06 14:37) [298]
Я задам вопрос такой, возвратившись к моей географии. Допустим, что кроме кода географического понятия по стандарту ISO, я еще решил ввести некий синтетический ключ, сообразно канонам - ID.
Для того, чтобы поддерживать его уникальность, в дополнение к уже уникальному коду, мне потребуется ввести дополнительный объект в базе данных (Sequence в Oracle, Generator в Interbase) вместе со всеми механизми его обслуживания (запрос на выборку очередного уникального значения из этого дополнительного объекта).
Внимание, вопрос - какие преимущества мне дает этот подход, кроме увеличения массы как программного кода, так и схемы базы данных ?
← →
Lamer@fools.ua © (2006-04-19 14:59) [300]>Внимание, вопрос - какие преимущества мне дает этот подход, кроме увеличения массы как программного кода, так и схемы базы данных ?
Я как бы не в курсе полной задачи. Имеется в виду [53]? То есть задача только хранить страны? Больше ничего не надо?
← →
Lamer@fools.ua © (2006-04-19 15:00) [301]P.S.
>То есть задача только хранить страны?
Ну и выбирать их, конечно.
← →
Игорь Шевченко © (2006-04-19 15:03) [302]Lamer@fools.ua © (19.04.06 15:00) [301]
Имеется в виду хранить страны, иметь с этими странами связанные таблицы с полезной информацией, загружать данные в эти таблицы из, в том числе, внешних источников и т.д.
> Я как бы не в курсе полной задачи
Пардоньте. Сторонники единообразного подхода в этой ветке говорили о преимуществах этого подхода безотносительно задач.
← →
euru © (2006-04-19 15:12) [303]
> vuk © (18.04.06 17:53) [241]
> Если нужно именно дату и номер, то надо вводить дату и номер,
> но дело в том, что обычно интерфейс проектируется так,
> чтобу вообще это дело свести к минимуму. То есть есть список
> документов на дату, где можно посмотреть любой документ,
> найти по номеру в списке и т.п. И ничего не надо вводить
> руками.
Т.е. вместо:
1. ввести номер сторнированного документа
2. получить данные этого документа
3. найти в полученном документе номер сторнирующего документа
Вы предлагаете пользователю:
1. ввести ограничивающие критерии для получения списка документов
2. дождаться получение списка
3. найти и выбрать из этого списка нужный документ
4. получить данные этого документа
5. найти в полученном документе номер сторнирующего документа
По-моему, как-то с производительностью и удобством пользователю не согласуется.
> > Наверно, для формирования списка сторнированных документов
> > нужно будет знать хотя бы их дату проводки, чтобы ограничить
> > этот список до разумных пределов. Получается, что JOIN переместится
> > в процедуру формирования этого списка.
>
> Если это нужно, то да, в процедуру формирования списка.
> Вопрос в том, нужно ли это.
Нужно, нужно. Иначе Вы просто выберите все сторнированные документы, которых за несколько лет работы накопилось великое множество. А это тоже вряд ли скажется на производительности.
> А вообще, если главным условием при проектировании делать
> минимизацию числа Join-ов, то можно вообще куда-нибудь не
> туда прийти в результате.
Упс. Минимизация JOIN-ов -- это не условие проектирования, а следствие использования естественных ключей.
А вот использование только суррогатных ключей -- это условие проектирования, из-за которого, как Вы выразились, "можно вообще куда-нибудь не туда прийти в результате".
← →
Lamer@fools.ua © (2006-04-19 15:16) [304]>>Игорь Шевченко © (19.04.06 15:03) [302]
>Пардоньте. Сторонники единообразного подхода в этой ветке говорили о преимуществах этого подхода безотносительно задач.
По большому счёту, так и есть.
Я предпочту один раз потратить время на то, чтобы настроить/сделать скрипт/утилиту/etc. для настройки ПК в виде identity/sequence/etc. (причём в качестве ПК буду использовать что-то родное процессору, — например, INT; GUID"ы мне не особо нравятся, если честно), чем потом при написании запросов помнить, что именно у таблицы стран ключ — ISO-код страны. Даже если пока что связей с этим справочником нет, они могут появится в будущем. А я рассматриваю системы, которые планируется расширять в будущем. Системы типа "курсовой проект, сдал и забыл" сюда не относятся, для них может использоваться несколько другой подход :-)
← →
Игорь Шевченко © (2006-04-19 15:23) [305]Lamer@fools.ua © (19.04.06 15:16) [304]
Я спрашивал про преимущества, вообще-то. Пусть даже с учетом расширения в будущем.
Мне кто-нибудь может ответить ?
← →
Sergey13 © (2006-04-19 15:51) [306]2[299] Игорь Шевченко © (19.04.06 14:54)
>Внимание, вопрос - какие преимущества мне дает этот подход, кроме увеличения массы как программного кода, так и схемы базы данных ?
Никакого, кроме независимости от стандарта ISO. Стандарты ведь тоже меняются, хоть и не часто. Вдруг завтра RU станет RUS или RF.
← →
Игорь Шевченко © (2006-04-19 16:18) [307]Sergey13 © (19.04.06 15:51) [306]
Пост № 256 перечитай. Мне не нужна независимость от стандарта ISO, мне нужно, чтобы под одним и тем же кодом те базы данных, с которыми я общаюсь, понимали одно и то же географическое понятие.
> Стандарты ведь тоже меняются, хоть и не часто
Если не трудно, приведи, плз, пример изменения стандарта ISO
← →
Lamer@fools.ua © (2006-04-19 16:20) [308]>>Игорь Шевченко © (19.04.06 15:23) [305]
Да, собственно, и преимущества и недостатки уже расписаны и у Тенцера, и в ссылке, что Вы приводили ранее. Какой мне смысл повторяться? Далее дело скорее личных пристрастий, опыта, ну и религиозных убеждений :-)
← →
Sergey Masloff (2006-04-19 16:24) [309]Sergey13 © (19.04.06 15:51) [306]
Чаще обратная проблема. Именно из-за изменчивости стандартов.
Страна уже есть а кода - нет.
← →
Sergey13 © (2006-04-19 16:28) [310]Последую примеру [149] Игорь Шевченко © (17.04.06 14:56)
и озвучу свою позицию.
Самое большое преимущество СК от ЕК - это независимость от внешнего мира. Это дает незыблемый фундамент для нерушимости связей - реляций. (о как задвинул! 8-)
Но нараду с СК в реальной БД хорошо использовать и альтернативный ключ (АК) для смысловой идентификации записи. Этот АК может состоять как из ссылок на СК, так и из ЕК.
Такое совмещение будет, ИМХО, наилучшим выходом. СК - для связей, ЕК - для поиска по таблице.
← →
Игорь Шевченко © (2006-04-19 16:31) [311]Lamer@fools.ua © (19.04.06 16:20) [308]
Виталий, я же спрашивал конкретно про свой случай, про то, какие преимущества мне дает введение дополнительного объекта в базу данных и механизма его использования вместо того, чтобы явно объявить ссылку на заведомо уникальное поле.
← →
Внук © (2006-04-19 16:52) [312]>>Игорь Шевченко © (19.04.06 16:31) [311]
Заполнить этот справочник самим разработчиком и сделать его доступным только на чтение. Нет вопросов.
← →
Игорь Шевченко © (2006-04-19 16:59) [313]Внук © (19.04.06 16:52) [312]
Тут есть такой момент - допустим, что некой части базы (скажем, территориально удаленной, попросту, филиалу предприятия) нет нужды держать полный справочник в силу предметной же области. И при получении данных с кодом, не находящимся в справочнике, воспринимать это как ошибку. Так что ведение должно остаться за пользователем.
← →
Sergey Masloff (2006-04-19 17:06) [314]Игорь Шевченко © (19.04.06 16:18) [307]
>Если не трудно, приведи, плз, пример изменения стандарта ISO
А какой там код у страны "Сербия и Черногория" ?
← →
vuk © (2006-04-19 17:37) [315]to euru © (19.04.06 15:12) [303]:
>Вы предлагаете пользователю:
Понимаете, обычно пользователи работают со списками документов. Обычно на конкретную дату. Отсюда и стоит плясать. А если исходить из абстрактной задачи получения номера связанного документа по исходному, то решение будет получено не менее абстрактное.
>Нужно, нужно. Иначе Вы просто выберите все сторнированные документы,
>которых за несколько лет работы накопилось великое множество.
См. выше. Обычно пользователи работают со списками документов. Обычно на конкретную дату.
>Упс. Минимизация JOIN-ов -- это не условие проектирования, а следствие
>использования естественных ключей.
Если будет нужно показать еще и автора операции, Вы его тоже в таблицу добавите вместе с ключом?
← →
Jeer © (2006-04-19 17:40) [316]Игорь Шевченко © (19.04.06 15:23) [305]
> Я спрашивал про преимущества
Говоришь, работаешь на FB ?
Так расскажи о возможности создания PK или пользовательского индекса для 4-х полей varchar(32) в условиях национальной collation.
Это как раз из того примера выше, чтоя привел.
При использовании СК этой проблемы вообще не возникает, как правило.
← →
Sergey Masloff (2006-04-19 17:45) [317]Jeer © (19.04.06 17:40) [316]
>Так расскажи о возможности создания PK или пользовательского индекса >для 4-х полей varchar(32) в условиях национальной collation.
Вроде пофиксили уже. Я что-то не слежу в последнее время но пробегало что толи в 1.5.2 толи в 2.0 раздвинули
← →
Jeer © (2006-04-19 17:50) [318]Sergey Masloff (19.04.06 17:45) [317]
Да, с двойки и в yaffil, но до этого весь мир стоял и ждал ?
Конечно же работали и использовали устойчивые к подобных делам структуры баз с СК
← →
xayam © (2006-04-19 17:52) [319]
> Игорь Шевченко © (19.04.06 10:12) [258]
> xayam © (19.04.06 01:24) [257]
> Видишь ли, организация ISO не ставит своей целью сформировать
> именно твое представление.
вопрос не в этом, а в том кто будет придерживаться этих стандартов, а кто нет. И это тоже надо учитывать. Ты согласен с тем что вечных стандартов нет? Почему же тогда я должен основывать на такой непостоянной почве свою базу?
> Объясни это говорящим на других языках. По крайней мере
> у тебя будет чем время занять.
Объяснять? Для этого просто добавляется поле с переводом на нужный язык
> Ничего не меняли. СССР было SU, Россия - RU. Никаких проблем
> для того, чтобы отличить, нету.
Отличить что? СССР вообще нет, это называется избыточность. И если они так меняют стандарты, то это как ком, он только больше и больше. А оно тебе надо?
← →
euru © (2006-04-19 18:12) [320]
> vuk © (19.04.06 17:37) [315]
> Понимаете, обычно пользователи работают со списками документов.
> Обычно на конкретную дату. Отсюда и стоит плясать. А если
> исходить из абстрактной задачи получения номера связанного
> документа по исходному, то решение будет получено не менее
> абстрактное.
Например, в нашей системе ежедневно генерируется 1000-2000 документов. Вы пользователю каждый раз открывать весь этот список и искать в нём нужный документ? Кроме того, конкретная дата может быть разной (сейчас мне понадобились текущие документы, через 5 мин -- недельной давности). Вы предлагаете держать по списку для каждой даты?
> См. выше. Обычно пользователи работают со списками документов.
> Обычно на конкретную дату.
Обычно пользователи работают с дебиторами/кредиторами или со счетами, и документы выбирают для них. А если они хотят посмотреть конкретный документ, то они просто вводят его номер и дату (списки для этого совершенно не нужны).
> Если будет нужно показать еще и автора операции, Вы его
> тоже в таблицу добавите вместе с ключом?
В этом нет необходимости, потому что номера и даты документа достаточно для его уникальности.
← →
Sergey Masloff (2006-04-19 18:31) [321]euru © (19.04.06 18:12) [320]
Что-то я не понимаю. А откуда пользователь этот номер возьмет? На память? А 10-значный номер не дольше набрать чем 3 раза мышем тыкнуть?
Про списки. Как правило есть какие-то стандартные варианты типа "мои за даень", "отдела за день" еще пара подобных. На них есть ярлыки то есть условия отбора указывать не надо. Про "ожидание" списка это несерьезно доли секунды он занимает даже для пользователя в трехзвенке на диалапе сидящего.
Вобщем по скорости получается то же а по удобству...
Ну нужно мне посмотреть документы в которых участником было ООО Рога и копыта номер неизвестен но известна примерная сумма и что было это в прошлом месяце вроде бы. И что должен вводить гипотетический юзер?
← →
Lamer@fools.ua © (2006-04-19 18:36) [322]>>Игорь Шевченко © (19.04.06 16:31) [311]
>Виталий, я же спрашивал конкретно про свой случай, про то, какие преимущества мне дает введение дополнительного объекта в базу данных и механизма его использования вместо того, чтобы явно объявить ссылку на заведомо уникальное поле.
Мы, наверное, просто размышляем по-разному. Для меня данное поле не является заведомо уникальным. Потому что в БД оно пришло извне.
В общем-то, я не пытаюсь кому-то доказать, что СК — серебряная пуля. Просто лично мне приятнее наступать на грабли, связаные с тем, что ПК является СК, а не ЕК.
← →
Jeer © (2006-04-19 18:40) [323]euru © (19.04.06 18:12) [320]
Понимание Вашей позиции полностью исчезло.
Какие списки ? Это Вы о комбобоксах чт-ли ?
И так можно для небольших справочников.
Для работы же со списками документов - надлежащая форма.
Пользователю предоставляется возможность выборки по условиям, жестким или мягким - это как сделано будет от потребностей.
← →
Игорь Шевченко © (2006-04-19 22:47) [324]xayam © (19.04.06 17:52) [319]
> вопрос не в этом, а в том кто будет придерживаться этих
> стандартов, а кто нет. И это тоже надо учитывать
Я не понимаю, какое отношение это имеет к типу ключей. Те, кто придерживается, обеспечивает безболезненный обмен данными, не вводя лишних сущностей, а больше, собственно, от задачи ничего не надо.
> Объяснять? Для этого просто добавляется поле с переводом
> на нужный язык
У тебя 100 стран, в которых говорят на разных языках. Будешь заводить 100 полей ? А смысл ?
> Отличить что? СССР вообще нет, это называется избыточность.
> И если они так меняют стандарты, то это как ком, он только
> больше и больше.
Заметь, стандарт не меняется. Была сущность СССР, кодировалась определенным сочетанием. Появилась самостоятельная сущность Россия, для нее выбрано другое сочетание. Никакого изменения стандарта нет.
← →
Игорь Шевченко © (2006-04-19 22:56) [325]Lamer@fools.ua © (19.04.06 18:36) [322]
> Для меня данное поле не является заведомо уникальным. Потому
> что в БД оно пришло извне.
А во внешнем мире не бывает уникальных значений ? :) На мой взгляд, бывают. Впрочем, до тех пор, пока их, в качестве уникальных, придерживаются те источники, с которыми мне нужно обмениваться данными, меня имеющаяся уникальность устраивает. Ну и заодно, мне не нужно делать дополнительных запросов при импорте, для выяснения того, какой синтетический ключ соответствует пришедшему коду, что на производительности тоже достаточно благотворно сказывается.
Опять же, я свою точку зрения никому не навязываю, просто продолжаю считать, что естественные ключи (или бизнес-ключи, по терминологии автора Keytaxonomy2005) тоже имеют право на существование в структуре базы данных и соображения об их неиспользовании выглядят в большей
степени религиозными, нежели практическими.
С наилучшими,
← →
xayam © (2006-04-19 23:28) [326]
> Игорь Шевченко © (19.04.06 22:47) [324]
> Я не понимаю, какое отношение это имеет к типу ключей.
Как это? Самое прямое. По нашему спору к этому все пришло.
> Те, кто придерживается
...а кто не придерживается беспомощен. Так что ли?
> обеспечивает безболезненный обмен данными
Да кто тебе сказал, что это первостепенная задача?
> не вводя лишних сущностей
сущности, улучшающие структуру (архитектуру, основу - как хочешь назови), не могут быть лишними!
> У тебя 100 стран, в которых говорят на разных языках. Будешь
> заводить 100 полей?
Если понадобится, то да. Но это опять же не суть. Важнее не сколько у тебя полей, а сколько строк, а их будет тем меньше в таблице, чем больше ты нормализуешь базу.
> А смысл ?
Очень простой - решить поставленную задачу.
> Заметь, стандарт не меняется. Была сущность СССР, кодировалась
> определенным сочетанием. Появилась самостоятельная сущность
> Россия, для нее выбрано другое сочетание. Никакого изменения
> стандарта нет.
Ты противоречишь себе
← →
Игорь Шевченко © (2006-04-19 23:40) [327]xayam © (19.04.06 23:28) [326]
> ...а кто не придерживается беспомощен. Так что ли?
А кто не придерживается, не обменивается со мной данными. Так я доступно излагаю ?
> Да кто тебе сказал, что это первостепенная задача?
Область задач моей предметной области сказала.
> Если понадобится, то да. Но это опять же не суть. Важнее
> не сколько у тебя полей, а сколько строк, а их будет тем
> меньше в таблице, чем больше ты нормализуешь базу.
Не понял, поясни. Особенно фразу насчет полей и строк. Ты считаешь, что 100 полей лучше чем 100 строк или как ? И какое отношение ко всему этому имеет нормализация ?
> сущности, улучшающие структуру (архитектуру, основу - как
> хочешь назови), не могут быть лишними!
Могут. И я привел пример в одном из предыдущих постов. Вот объясни мне, каким образом введенные лишние сущности (объекты базы данных для генерации синтетических уникальных значений, сопоставляемых с естественно уникальными значениями) улучшат архитектуру моей системы. Если не трудно, объясни подробнее.
> Ты противоречишь себе
Суть стандарта - каждая страна имеет свой уникальный код. В чем я себе противоречу ?
← →
xayam © (2006-04-20 00:06) [328]
> Игорь Шевченко © (19.04.06 23:40) [327]
> А кто не придерживается, не обменивается со мной данными
Очень надо было))
> Область задач моей предметной области сказала.
Какая?
> Ты считаешь, что 100 полей лучше чем 100 строк или как ?
100 полей - это, можно сказать, константа, а количество строк - переменная. Их нельзя сравнивать.
> И какое отношение ко всему этому имеет нормализация ?
Так, так домашнее задание не сделали, не узнали что такое нормализация. Есть такое понятие Универсальная Отношение, такая большая таблица, которая изначально содержит все поля и строки, включая дублирующие. Так вот в процессе нормализации (разделения, декомпозиции - как хочешь) количество таблиц увеличивается, строк, относящихся к какому-либо факту, уменьшается. И этот процесс необходим, если Вы хотите исключить из базы избыточность информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных. Окончательная цель - каждый факт появляется лишь в одном месте.
> Суть стандарта - каждая страна имеет свой уникальный код
А про ком ты уже забыл?
> В чем я себе противоречу ?
"Никакого изменения стандарта нет". Скорей всего ты хочешь сказать, что он обратно совместим.
← →
Игорь Шевченко © (2006-04-20 00:21) [329]xayam © (20.04.06 00:06) [328]
> Очень надо было))
Некоторым надо. Я не ставлю себе всеобъемлющих задач, поэтому можешь не обмениваться, твое полное право.
> И этот процесс необходим, если Вы хотите исключить из базы
> избыточность информации
Спасибо, у меня избыточность исключительно в разумных пределах. Как ты читал дальше, нормализация - это конечно очень хорошо, но не очень производительно.
> А про ком ты уже забыл?
???? Про какой ком ?
> "Никакого изменения стандарта нет". Скорей всего ты хочешь
> сказать, что он обратно совместим
Нет. Никакого изменения стандарта нет. СССР был точно такой же страной, какой является Россия и имеет свой уникальный код. Ни о совместимости ни об изменениях речь не идет.
> 100 полей - это, можно сказать, константа, а количество
> строк - переменная. Их нельзя сравнивать.
Еще раз: ты сказал, что проблема с разными названиями стран на разных языках решается добавлением поля с названием на другом языке. В посте [326] ты сказал, что добавишь 100 полей, если надо учитывать названия на 100 языках. Тебе не кажется, что ты в этом случае сильно отступаешь от нормализации ?
← →
xayam © (2006-04-20 00:22) [330]
> Игорь Шевченко © (19.04.06 23:40) [327]
> каким образом введенные лишние сущности улучшат архитектуру
> моей системы
очень просто - она не будет зависеть от внешнего мира (о чем я писал в самом начале). Круг замкнулся?
← →
xayam © (2006-04-20 00:32) [331]
> Игорь Шевченко © (20.04.06 00:21) [329]
> Я не ставлю себе всеобъемлющих задач
вот это зря
> нормализация - это конечно очень хорошо, но не очень производительно
о какой производительности ты говоришь? Которую не хочешь признавать на примерах Jeer"а ?
> Нет. Никакого изменения стандарта нет. СССР был точно такой
> же страной, какой является Россия и имеет свой уникальный
> код. Ни о совместимости ни об изменениях речь не идет.
...без комментариев
> Еще раз: ты сказал, что проблема с разными названиями стран
> на разных языках решается добавлением поля с названием на
> другом языке. В посте [326] ты сказал, что добавишь 100
> полей, если надо учитывать названия на 100 языках.
сделать перевод
> Тебе не кажется, что ты в этом случае сильно отступаешь
> от нормализации ?
В чем? Конкретнее?
← →
xayam © (2006-04-20 00:42) [332]
> Игорь Шевченко © (20.04.06 00:21) [329]
> > А про ком ты уже забыл?
> ???? Про какой ком ?
xayam © (19.04.06 17:52) [319]
← →
Lamer@fools.ua © (2006-04-20 00:42) [333]>>Игорь Шевченко © (19.04.06 22:56) [325]
>А во внешнем мире не бывает уникальных значений ? :) На мой взгляд, бывают. Впрочем, до тех пор, пока их, в качестве уникальных, придерживаются те источники, с которыми мне нужно обмениваться данными, меня имеющаяся уникальность устраивает. Ну и заодно, мне не нужно делать дополнительных запросов при импорте, для выяснения того, какой синтетический ключ соответствует пришедшему коду, что на производительности тоже достаточно благотворно сказывается.
Даже если ПК у меня СК, ничто мне не мешает в данный момент, пока действует какая-то договорённость об уникальности поля (стандарт или спецификация по обмену данными с другими системами) навесить ограничение уникальности на, скажем, ISO-код страны (или региона?) и использовать ISO-код для синхронизации, например, с Вашей системой. Вполне возможно, что пройдёт время и придумают новый стандарт, а на старый махнут рукой. Что тогда делать, если ПК — ISO-код? Придумывать алгоритм генерации? Либо изменять структуру БД и обновлять данные, чтобы использовать новый код? С некоторой стороны это, конечно, выгодно — есть за что брать деньги :-)
Резюмирую. IMHO, СК бывает и излишним, но добавляет универсальность и унифицированность.
>Опять же, я свою точку зрения никому не навязываю, просто продолжаю считать, что естественные ключи (или бизнес-ключи, по терминологии автора Keytaxonomy2005) тоже имеют право на существование в структуре базы данных...
Да пускай себе существуют. Но не в виде ПК, а в виде UNIQUE CONSTRAINT"ов :-)
Я, собственно, тоже не навязываю. Да и хлопотно и накладно это как-то — навязывать :-)
>...и соображения об их неиспользовании выглядят в большей
степени религиозными, нежели практическими.
IMHO, холиворы интереснее наблюдать со стороны, чем принимать в них непосредственное участие :-)
← →
Игорь Шевченко © (2006-04-20 00:43) [334]xayam © (20.04.06 00:22) [330]
> очень просто - она не будет зависеть от внешнего мира
Но я не ставлю целью независимость от внешнего мира, более того, я с этим внешним миром активно взаимодействую, равно, как и он со мной. Не бывает систем, данные в которых циркулируют только внутри этих систем, не приходя из внешнего мира, и не выходя наружу во внешний мир.
> вот это зря
Почему ?
> о какой производительности ты говоришь? Которую не хочешь
> признавать на примерах Jeer"а ?
Будет скрипт, будет производительность. Я говорю о той производительности, падение которой является оборотной стороной нормализации. Я приводил статью KeyTaxonomy2005, там этот момент тоже, по-моему, упоминается.
> сделать перевод
> В чем? Конкретнее?
Ну в том, хотя бы, что поля в таблице не должны зависеть друг от друга. А между названиями на разных языках зависимость довольно сильная, не находишь ?
> ...без комментариев
Я что-то сказал не так или ты, наконец, согласился ? :)
← →
xayam © (2006-04-20 00:48) [335]
> Lamer@fools.ua © (20.04.06 00:42) [333]
> Но не в виде ПК, а в виде UNIQUE CONSTRAINT"ов :-)
поддерживаю
← →
Игорь Шевченко © (2006-04-20 00:53) [336]Lamer@fools.ua © (20.04.06 00:42) [333]
> ничто мне не мешает в данный момент, пока действует какая-
> то договорённость об уникальности поля (стандарт или спецификация
> по обмену данными с другими системами) навесить ограничение
> уникальности на, скажем, ISO-код страны (или региона?) и
> использовать ISO-код для синхронизации, например, с Вашей
> системой. Вполне возможно, что пройдёт время и придумают
> новый стандарт, а на старый махнут рукой. Что тогда делать,
> если ПК — ISO-код?
Сдается мне, что ко времени изменения стандарта ISO накопится масса других, более актуальных изменений в структуре базы данных.
Но и это не главное. А главное то, что этих стандартов придерживаются системы, с которыми я взаимодействую, что для меня гораздо важнее, чем уповать на то, что стандарты, дескать, поменяются. Кстати, стандарты ISO не меняются. Могут появляться новые стандарты, но старые не исчезают.
> Резюмирую. IMHO, СК бывает и излишним, но добавляет универсальность
> и унифицированность.
А какой выигрыш дает универсальность и унифицированность, что ради нее нужно вводить лишние механизмы ?
> Да пускай себе существуют. Но не в виде ПК, а в виде UNIQUE
> CONSTRAINT"ов :-)
А какой смысл держать два уникальных constraint в одной сущности ? Я понимаю, когда одно поле используется для связки, потому что небольшое, а другая группа полей составляет уникальный constraint, но в моем случае вроде оба поля небольшие и вполне могут использоваться для связки.
ЗЫ: Оффтопик: А чего ты старым ником не пользуешься ? :)
← →
xayam © (2006-04-20 01:07) [337]
> Игорь Шевченко © (20.04.06 00:43) [334]
> А между названиями на разных языках зависимость
соответствие.
Я правильно понял?
ID Pole_ISO Pole_Rus Pole_Eng Pole_Fr ...
0 RU Россия Russia La Russie Rusia Rußland
1 UK ...
...
----------------------------------------------------------------
> Я что-то сказал не так
Да и не спрашивай что. Почитай сам свой текст
> или ты, наконец, согласился ?
нет, но не парься, как [] догоним до 1000, я над этим подумаю))
← →
Lamer@fools.ua © (2006-04-20 01:10) [338]>>Игорь Шевченко © (20.04.06 00:53) [336]
>А какой выигрыш дает универсальность и унифицированность, что ради нее нужно вводить лишние механизмы ?
А вот ответ на этот вопрос уже зависит от целевой системы. Вполне допускаю, что оные не для каждой системы и нужны.
>А какой смысл держать два уникальных constraint в одной сущности ? Я понимаю, когда одно поле используется для связки, потому что небольшое, а другая группа полей составляет уникальный constraint, но в моем случае вроде оба поля небольшие и вполне могут использоваться для связки.
На компрометирующие мою религию вопросы я буду отвечать только в присутствии Анатолия Тенцера :-))
А вообще сложно ответить, не видя конкретного SRS. Вполне допускаю, что в тех типах систем, с которыми я не сталкивался, ЕК рулят, а СК — сакс и мастдай.
>ЗЫ: Оффтопик: А чего ты старым ником не пользуешься ? :)
Даже сам не знаю.
Может, потому что под этим ником я в большем количестве форумов зарегистрирован и решил, так ска-ать и тут провести унификацию :-)
Или может, потому что почти перестал отвечать в тематических конференциях, а для потрепаловки этот ник в самый раз.
← →
Игорь Шевченко © (2006-04-20 01:13) [339]xayam © (20.04.06 01:07) [337]
> Я правильно понял?
> ID Pole_ISO Pole_Rus Pole_Eng Pole_Fr ...
> 0 RU Россия Russia La Russie Rusia
> Rußland
> 1 UK ...
Ты этот вариант хочешь предложить ? Я не принимаю. Количество языков, с которыми мне приходится общаться, переменный. В сторону увеличения.
> > Я что-то сказал не так
>
> Да и не спрашивай что. Почитай сам свой текст
Я свой текст читаю. Если ты видишь в нем несоответстие чему-то, то ты не стесняйся, а прямым текстом укажи, где я неправ.
> нет, но не парься, как [] догоним до 1000, я над этим подумаю))
Я не в бане, дружок.
← →
Anatoly Podgoretsky © (2006-04-20 01:18) [340]А что тебя взволновал СОМ, какое он отношение к странам имеет?
← →
Игорь Шевченко © (2006-04-20 01:18) [341]Lamer@fools.ua © (20.04.06 01:10) [338]
> А вот ответ на этот вопрос уже зависит от целевой системы.
> Вполне допускаю, что оные не для каждой системы и нужны.
>
Так об чем большевики твердят на протяжении всей этой ветки до хрипоты - что каждый овощ приносит пользу, будучи употреблен надлежащим образом в надлежащее время :)
> А вообще сложно ответить, не видя конкретного SRS.
И это большевики еще в самом начале ветки говорили :) Каждой системе, по-хорошему, не вредит свой подход со своими же тараканами.
> Или может, потому что почти перестал отвечать в тематических
> конференциях
А это зря, кстати :) В той же WinAPI, например.
← →
xayam © (2006-04-20 01:19) [342]
> Игорь Шевченко © (20.04.06 01:13) [339]
> прямым текстом укажи, где я неправ.
А я указал xayam © (19.04.06 23:28) [326]
> Количество языков, с которыми мне приходится общаться, переменный.
> В сторону увеличения.
Переменный, но ограниченный числом, скажем, 100. А количество строк - их же может быть куда больше.
← →
xayam © (2006-04-20 01:21) [343]
> Anatoly Podgoretsky © (20.04.06 01:18) [340]
читайте пожалуйста все, и я сказал "ком", а не "COM".
← →
xayam © (2006-04-20 01:24) [344]
> Игорь Шевченко © (20.04.06 01:13) [339]
> с которыми мне приходится общаться
Может ты все таки откроешь свою область деятельности, можешь на почту, я никому не скажу))
← →
Игорь Шевченко © (2006-04-20 01:27) [345]
> > Заметь, стандарт не меняется. Была сущность СССР, кодировалась
>
> > определенным сочетанием. Появилась самостоятельная сущность
>
> > Россия, для нее выбрано другое сочетание. Никакого изменения
>
> > стандарта нет.
>
> Ты противоречишь себе
Под сущностью имеется в виду экземпляр сущности типа страна, если быть до конца точным. И СССР и Россия - это страны.
Теперь возражений нет ?
← →
xayam © (2006-04-20 01:30) [346]
> Игорь Шевченко © (20.04.06 01:27) [345]
> экземпляр сущности типа страна, если быть до конца точным.
> И СССР и Россия - это страны
еще раз - СССР нет, что ты за нее так держишься?
← →
Anatoly Podgoretsky © (2006-04-20 08:53) [347]xayam © (20.04.06 01:30) [346]
Если бы было все так просто в базах, пропала сущность, стерли ее, что бы за нее не держаться и глаза не можолить.
← →
Игорь Шевченко © (2006-04-20 10:13) [348]xayam © (20.04.06 01:30) [346]
Еще два раза - до 1991 года он был, а стандарт был сделан несколько раньше.
← →
Внук © (2006-04-20 10:19) [349]И бились они три дня и три ночи, и не было им усталости
← →
xayam © (2006-04-20 10:46) [350]
> Игорь Шевченко © (20.04.06 10:13) [348]
> Еще два раза - до 1991 года он был, а стандарт был сделан
> несколько раньше.
Да какая разница раньше, позже. Стандарт изменился, упоминание об СССР осталось (я правильно понял?), чтобы никто не использовал это сочетание. А зачем мне в базе отражать историю стандарта, скажите? База данных - отражение реальности, то что есть, ни больше, ни меньше.
← →
Игорь Шевченко © (2006-04-20 10:47) [351]xayam © (20.04.06 10:46) [350]
> А зачем мне в базе отражать историю стандарта, скажите?
А тебя кто-то заставляет отражать ? Вроде нет.
← →
xayam © (2006-04-20 10:54) [352]
> Игорь Шевченко © (20.04.06 10:47) [351]
Стоп. С этого места подробнее. Не заставлял? О какой поддерже стандарта ты тогда говоришь? Пожалуйста приведи свой вариант таблицы, которая была выше.
← →
Игорь Шевченко © (2006-04-20 10:57) [353]xayam © (20.04.06 10:54) [352]
Я говорю о том, что код ISO используется в качестве первичного ключа в таблицах, описывающих географические понятия, и в качестве поля для связки. И все. Про СССР начал ты говорить.
← →
xayam © (2006-04-20 11:06) [354]
> Игорь Шевченко © (20.04.06 10:57) [353]
> Я говорю о том, что код ISO используется в качестве первичного
> ключа в таблицах, описывающих географические понятия, и
> в качестве поля для связки.
страны
> Про СССР начал ты говорить.
да, но таких СССР в стандарте все больше и больше - вот это и есть ком. Ну может не очень хорошее сравнение, скажи сосулька - она все больше и больше намерзает, а когда упадет. Ты знаешь об этом?
> Я говорю о том
А со 100 полями у тебя как, по-другому?
← →
Anatoly Podgoretsky © (2006-04-20 11:29) [355]xayam © (20.04.06 11:06) [354]
О каком таинственном ком ты говоришь
← →
sniknik © (2006-04-20 11:35) [356]Игорь Шевченко © (20.04.06 10:57) [353]
> Я говорю о том, что код ISO используется в качестве первичного ключа в таблицах, описывающих географические понятия,
> и в качестве поля для связки.
используете и используйте на здоровье... скажите только код у вас этот только для связок, или еще и в отчетах гденибудь используется? /в таблицах/для выбора из списка? т.е. юзер его видит? думаю да.
и теперь представьте ситуацию, клиент "заартачился", не хочу говорит видеть код в ISO 639-1 варианте, хочу в ISO 639-2 ....
http://ru.wikipedia.org/wiki/ISO_639
и ? он у вас уже в куче документов за 6 лет (к примеру) присутствует, + в архивах, на местах в распределенной системе.
нетрудно догадатся, что вам придется это править весде, во всех вторичных документах, в отличие от если бы использовался искуственный ключ, тут бы поправили только основной справочник.
это к вопросу о
sniknik © (17.04.06 11:37) [81]
> исправить сложнее, если конечно ИНН используется как естественный ключь.
Игорь Шевченко © (17.04.06 11:40) [82]
> sniknik © (17.04.06 11:37) [81]
> Может, я чего здорово не понимаю, но в чем именно сложность ?
иправлений, ошибочно введенных ИНН.
p.s. возможно аргумент не раз уже приводили... сорри, перестал следить за веткой.
p.p.s. а после того как исправите, клиент посмотрит и скажет "не, раньше лучше было" ;о)))
← →
xayam © (2006-04-20 11:40) [357]
> Anatoly Podgoretsky © (20.04.06 11:29) [355]
тот который снежный
← →
Внук © (2006-04-20 11:42) [358]>>sniknik © (20.04.06 11:35) [356]
Не человек для субботы, а суббота для человека :)
У них клиенты не артачатся, они с такими не работают
← →
xayam © (2006-04-20 11:47) [359]
> Внук © (20.04.06 11:42) [358]
> >>sniknik © (20.04.06 11:35) [356]
> они с такими не работают
)) Очень надо было скажет
← →
Игорь Шевченко © (2006-04-20 12:02) [360]sniknik © (20.04.06 11:35) [356]
> и теперь представьте ситуацию, клиент "заартачился",
Даже представлять не буду. Если под каждого клиента навешивать свои рюшечки, это значит, обрекать себя на непроизводительный геморрой. А оно надо ?
← →
xayam © (2006-04-20 12:08) [361]
> Игорь Шевченко © (20.04.06 12:02) [360]
> А оно надо ?
Тебе вроде за это деньги платят. Или нет?
← →
sniknik © (2006-04-20 12:22) [362]> А оно надо ?
надо. если хотите заполучить больше клиентов и включить в сферу деятельности например Бурятию...
и потом если ипользовать искуственный ключь, то у записи на нем может быть несколько значений которые юзер может просто выбирать (а то и вбить собственные интерпретиции). т.е. немного больше мороки вначали, и в результате более гибкая, расширяемая система.
p.s. на этот раз окончательный ;о), никто никого не переубедит.... в общемто [356] это не попытка переубеждений а запоздалый ответ на вопрос "почему с искуственным исправить сложнее".
← →
vovnuke © (2006-04-20 12:52) [363]
> [210] euru © (18.04.06 11:39)
Покажите мне пожалуйста хоть один пример реально удачного внедрения этой системы в России.
> [336] Игорь Шевченко © (20.04.06 00:53)
> А какой смысл держать два уникальных constraint в одной
> сущности ?
Один для базы данных, другой для польщователя.
← →
Хозяин (2006-04-20 13:05) [364]Я правильно понял?
ID Pole_ISO Pole_Rus Pole_Eng Pole_Fr ...
0 RU Россия Russia La Russie Rusia Ru?land
1 UK ...
видимо так...Pole_local_ISO Pole_removed_ISO Pole_Country_Name
RU FR Франция
RU US США
FR RU La Russie
FR US La America
US RU Russia
US FR France
...
← →
Внук © (2006-04-20 13:09) [365]Removed и Remote - это разные слова :)
← →
Хозяин (2006-04-20 13:12) [366]Внук © :)
да я сомневался, ну и "сократом" - сократнул :) (удаленный)
← →
Игорь Шевченко © (2006-04-20 13:18) [367]sniknik © (20.04.06 12:22) [362]
> надо. если хотите заполучить больше клиентов
Да мы не жалуемся. Спор какой-то из-за выеденного яйца. Не зная задачи, не зная области применения, народ полагает, что я что-то делаю не так, согласно их религиозным канонам. Детский сад, штаны на лямках, ей-богу.
← →
xayam © (2006-04-20 13:21) [368]
> Игорь Шевченко © (20.04.06 13:18) [367]
> Да мы не жалуемся.
Значит Вы ничего не делаете
> Спор какой-то из-за выеденного яйца
Отдели структуру базы от содержания и спора не будет
> Не зная задачи, не зная области применения
раскрой тайну
> Детский сад, штаны на лямках, ей-богу
несерьезно говоришь
← →
Игорь Шевченко © (2006-04-20 13:24) [369]xayam © (20.04.06 13:21) [368]
Тебе не кажется несерьезным наставлять меня на путь истинный не зная ничего ни об области применения, ни о решаемых задачах ? Вот мне просто интересно. Про каноны можешь мне не рассказывать, если бы естестенные ключи были бы абсолютным злом, их возможность была бы убрана производителями СУБД.
← →
xayam © (2006-04-20 13:26) [370]
> Игорь Шевченко © (20.04.06 13:24) [369]
> не зная ничего ни об области применения, ни о решаемых задачах
если ты этого еще не понял, то это не важно по большому счету, я говорю "БЕЗОТНОСИТЕЛЬНО К ЗАДАЧИ"
← →
xayam © (2006-04-20 13:28) [371]
> их возможность была бы убрана производителями СУБД
каким образом?
← →
Игорь Шевченко © (2006-04-20 13:36) [372]
> если ты этого еще не понял, то это не важно по большому
> счету, я говорю "БЕЗОТНОСИТЕЛЬНО К ЗАДАЧИ"
Ну прочитай ты, что люди пишут.
http://www.ncom.ru/downloads/KeyTaxonomy2005ru.pdf
А потом говори про безотносительность.
← →
vovnuke © (2006-04-20 13:36) [373]
> [369] Игорь Шевченко © (20.04.06 13:24)
Никто не говорит, что естественные ключи это зло, просто:
- естественные ключи предназначены для определения понятий с которыми работает пользователь.
- искусственные для базы данных.
И надо каждые из них использовать в своей области.
← →
Игорь Шевченко © (2006-04-20 13:38) [374]vovnuke © (20.04.06 13:36) [373]
> И надо каждые из них использовать в своей области.
Ну объясни ты мне, какой смысл городить огород из искусственных ключей, вводить дополнительные объекты, если в предметной области уже присутствуют атрибуты, подходящие на роль ключей. Объяснить желательно цитатой из Кодда.
← →
vovnuke © (2006-04-20 13:49) [375]
> [374] Игорь Шевченко © (20.04.06 13:38)
Если вы придерживаться терминологии, используемой в http://www.ncom.ru/downloads/KeyTaxonomy2005ru.pdf, то тогда мы с вами про разные вещи разговариваем.
Придерживаясь этой терминологиии:
- под искусственным ключом я понимаю:
"внутренние ключи" полученные искусственным образом,
- под естественным ключом "бизнес ключ", а вот бизнес ключом может быть как "искусственные" так и "естественные", что уже зависит от поставленной задачи.
Так что надо бы всем сначало определиться с терминологией, а то весело получается.
← →
xayam © (2006-04-20 13:51) [376]
> Игорь Шевченко © (20.04.06 13:36) [372]
"...Значение искусственного ключа формируется в БД и публикуется для использования во внешнем мире. Обратно, естественный ключ формируется неким сторонним для БД источником..."
это никак не должно быть связано со структурой базы
"...Понятно, что относительно этого источника ключ будет искусственным. Т.е если в одной БД ключ естественный, то где-то существует информационная система, где он является искусственным, ибо никто и ничто не рождается и не возникает с готовым именем или номером..."
где-то это где?
"...Люди, компании, планеты, показания датчиков, получают имена и иные «естественные» ключи посредством регистрации некоторой признанной организацией. По своему масштабу этой организацией может быть международное агентство по поддержке стандарта ISO 3166..."
может, а может и не быть, об этом уже говорили
← →
Внук © (2006-04-20 13:53) [377]>>Игорь Шевченко © (20.04.06 13:38) [374]
А Кодду мы верим, поскольку это никакая не религия :)
← →
Игорь Шевченко © (2006-04-20 14:11) [378]xayam © (20.04.06 13:51) [376]
Это вопросы мне или автору статьи ?
vovnuke © (20.04.06 13:49) [375]
Изначально в этой ветке разговор шел только о двух типах ключей - естественных и искусственных. Под искусственными здесь понимались ключи, сгенерированные конкретной базой данных для обеспечения уникальности и удобства связи таблиц. Корректируя свою мысль, в соответствии с [375], я говорю, что не только сгенерированные базой данных значения являются кандидатами на роль первичных ключей для таблиц, а и те, которые по терминологии из http://www.ncom.ru/downloads/KeyTaxonomy2005ru.pdf называются бизнес-ключами или естественными ключами.
Внук © (20.04.06 13:53) [377]
А Кодд приводит более убедительные доводы, чем высказывания в ветке.
← →
Внук © (2006-04-20 14:13) [379]>>Игорь Шевченко © (20.04.06 14:11) [378]
А пророки всегда убедительнее. Это я тебе как краевед :)
← →
xayam © (2006-04-20 14:14) [380]
> Игорь Шевченко © (20.04.06 14:11) [378]
> xayam © (20.04.06 13:51) [376]
> Это вопросы мне или автору статьи ?
К тебе. Ты же него ссылаешься. Поэтому я тебе его словами говорю.
← →
Игорь Шевченко © (2006-04-20 14:29) [381]Внук © (20.04.06 14:13) [379]
Так апостолы же не приводят убедительных доводов. Вот и приходится к первоисточникам обращаться.
xayam © (20.04.06 13:51) [376]
> естественный ключ формируется неким сторонним для БД источником.
> .."
> это никак не должно быть связано со структурой базы
Почему, из каких соображений это не должно быть ?
> где-то это где?
Где-то - это в другой системе.
Например, в информационной системе ISO.
> может, а может и не быть, об этом уже говорили
Ты можешь не доверять стандартам, это твое полное право. Но стандартам от твоего недоверия ни горячо, ни холодно. Я тебе могу еще раз повторить - стандарт - это способ установления однозначного понятия для всех, кто принимает и использует этот стандарт. Если ты его не принимаешь, это твое право, но критика без достаточных оснований тех, кто принимает, выглядит детским садом.
← →
vovnuke © (2006-04-20 14:30) [382]2 [378] Игорь Шевченко © (20.04.06 14:11)
> не только сгенерированные базой данных значения являются
> кандидатами на роль первичных ключей для таблиц, а и те,
> которые по терминологии из http://www.ncom.ru/downloads/KeyTaxonomy2005ru.pdf
> называются бизнес-ключами или естественными ключами
Вот здесь я с вами не согласен, так как говоря вашими словами:
> [341] Игорь Шевченко © (20.04.06 01:18)
> каждый овощ приносит пользу, будучи употреблен
> надлежащим образом в надлежащее время
База должна работать со своими атрибутами пользователь со своими, и не надо смешивать эти вещи.
← →
xayam © (2006-04-20 14:37) [383]
> Игорь Шевченко © (20.04.06 14:29) [381]
> из каких соображений это не должно быть ?
Так ну свои соображения уже приводил. Теперь по Кодду. Как там у него? 12 правил. Напомни 9-11 пожалуйста.
"9. ЛОГИЧЕСКАЯ НЕЗАВИСИМОСТЬ ДАННЫХ. Прикладные программы не должны зависеть от логических ограничений.
10. НЕЗАВИСИМОСТЬ КОНТРОЛЯ ЦЕЛОСТНОСТИ. Все необходимое для поддержания целостности данных, должно храниться в словаре данных.
11. ДИСТРИБУТИВНАЯ НЕЗАВИСИМОСТЬ. Реляционная БД должна быть переносимой и способной к распространению."
Вроде так? Или нет?
← →
Игорь Шевченко © (2006-04-20 14:40) [384]xayam © (20.04.06 14:37) [383]
Все правильно. Использование естественных или бизнес-ключей этим правилам не противоречит. Независимость налицо, переносимость налицо, поддержка целостности налицо.
vovnuke © (20.04.06 14:30) [382]
> База должна работать со своими атрибутами пользователь со
> своими, и не надо смешивать эти вещи
На основании чего делается такой вывод ? (Кто с чем должен работать и почему не надо смешивать) ?
← →
euru © (2006-04-20 14:51) [385]
> vovnuke © (20.04.06 12:52) [363]
> > [210] euru © (18.04.06 11:39)
> Покажите мне пожалуйста хоть один пример реально удачного
> внедрения этой системы в России.
Ну, например, у нас. :)
← →
xayam © (2006-04-20 14:51) [386]
> Игорь Шевченко © (20.04.06 14:40) [384]
> "...10. НЕЗАВИСИМОСТЬ КОНТРОЛЯ ЦЕЛОСТНОСТИ. Все необходимое
> для поддержания целостности данных, должно храниться в словаре
> данных..."
Да о каком контроле ты можешь говорить? Ты что можешь контролировать другую базу? Так что ли?
> "...11. ДИСТРИБУТИВНАЯ НЕЗАВИСИМОСТЬ. Реляционная БД должна
> быть переносимой и способной к распространению..."
Заметь без всяких условий, есть ISO или нет его, базе на это вообще с большой горы...
> "...9. ЛОГИЧЕСКАЯ НЕЗАВИСИМОСТЬ ДАННЫХ. Прикладные программы
> не должны зависеть от логических ограничений..."
Мутно конечно написано у Кодда, но ему это простительно, он же хотел все охватить! Как я это понимаю - это как раз "отделить мух от котлет" или "структуру от содержания" или "база должна работать со своими атрибутами пользователь со своими" - все одно и тоже.
← →
euru © (2006-04-20 14:59) [387]
> xayam © (20.04.06 14:37) [383]
> Так ну свои соображения уже приводил. Теперь по Кодду. Как
> там у него? 12 правил. Напомни 9-11 пожалуйста.
> "9. ЛОГИЧЕСКАЯ НЕЗАВИСИМОСТЬ ДАННЫХ. Прикладные программы
> не должны зависеть от логических ограничений.
> 10. НЕЗАВИСИМОСТЬ КОНТРОЛЯ ЦЕЛОСТНОСТИ. Все необходимое
> для поддержания целостности данных, должно храниться в словаре
> данных.
> 11. ДИСТРИБУТИВНАЯ НЕЗАВИСИМОСТЬ. Реляционная БД должна
> быть переносимой и способной к распространению."
Обратим внимание на то, что "всё необходимое ... должно храниться в словаре данных".Словарь данных и структура БД -- это две большие разницы.
← →
Игорь Шевченко © (2006-04-20 15:11) [388]xayam © (20.04.06 14:51) [386]
> Да о каком контроле ты можешь говорить? Ты что можешь контролировать
> другую базу? Так что ли?
Конечно. Использование стандарта автоматически обеспечивает контроль.
> Как я это понимаю
Ты ошибаешься и придаешь не тот смысл высказыванию Кодда.
← →
xayam © (2006-04-20 15:14) [389]
> Игорь Шевченко © (20.04.06 15:11) [388]
> Использование стандарта автоматически обеспечивает контроль.
в том то и дело, что НЕТ.
> > Как я это понимаю
> Ты ошибаешься и придаешь не тот смысл высказыванию Кодда.
расскажи о своем понимании
← →
vovnuke © (2006-04-20 15:17) [390]
> [385] euru © (20.04.06 14:51)
> Ну, например, у нас. :)
Это, простите что за компания? Сколько времени она у вас внедрялась? Сколько было положено сил для адаптации данной системы под Россию? И на самом ли деле она так уж хорошо работает? И стоит ли она своих денег?
> [384] Игорь Шевченко © (20.04.06 14:40)
> На основании чего делается такой вывод ? (Кто с чем должен
> работать и почему не надо смешивать) ?
см.
> [386] xayam © (20.04.06 14:51)
> > "...9. ЛОГИЧЕСКАЯ НЕЗАВИСИМОСТЬ ДАННЫХ. Прикладные программы
>
> > не должны зависеть от логических ограничений..."
плюс, собственное понимание проблемы. Это не верно - смешивать функции атрибутов базы данных с функциями атрибутов, которые необходимы для работы пользователей. Перегрузка.
← →
vovnuke © (2006-04-20 15:18) [391]Молоток тоже универсальный инструмент, им тоже можно много чего делать, но это не значит чтоэто нужно делать.
← →
xayam © (2006-04-20 15:21) [392]
> euru © (20.04.06 14:59) [387]
> должно храниться в словаре данных
А словарь данных это по Вашей терминологии что?
← →
Игорь Шевченко © (2006-04-20 15:28) [393]xayam © (20.04.06 15:14) [389]
> в том то и дело, что НЕТ.
Почему же ? Если каждая база обеспечивает соответствие географическому понятию кода ISO, то почему контроля-то нет ?
> Прикладные программы
> > не должны зависеть от логических ограничений..."
> расскажи о своем понимании
А я понимаю буквально, как написано.
vovnuke © (20.04.06 15:17) [390]
> Это не верно - смешивать функции атрибутов базы данных с
> функциями атрибутов, которые необходимы для работы пользователей
Дорогой друг, объясни пожалуйста, почему не верно. Мне впрямь интересно. Кроме того, с базой работают не сколько пользователи, сколько программы.
> . Перегрузка.
Перегрузка ЧЕГО ? Пользователей, базы, программы ? О какой перегрузке идет речь и почему не идет речь о перегрузке, когда согласно канонам требуется вводить дополнительные поля для обеспечения уникальности уникальных значений ?
← →
euru © (2006-04-20 15:34) [394]
> vovnuke © (20.04.06 15:17) [390]
> Это, простите что за компания? Сколько времени она у вас
> внедрялась? Сколько было положено сил для адаптации данной
> системы под Россию? И на самом ли деле она так уж хорошо
> работает? И стоит ли она своих денег?
1. Коммерческая.
2. Внедрение заняло 1 год.
3. SAP R/3 уже давно адаптирован под Российское законодательство, так что сил на адаптацию практически затрачено не было. Здесь главное не изобретать велосипед, а использовать уже наработанное.
4. На работу не жалуемся. На данный момент в системе работает 3 завода, к июлю ещё 2 присоединится. Также планируется расширение спектра решаемых системой задач.
5. Я думаю, если бы это было невыгодно, руководство компании не думало бы о расширении системы.
← →
xayam © (2006-04-20 15:35) [395]
> Игорь Шевченко ©
Ладно, мне кажется уже все сказано, каждый остался при своем. Думал до [1000] доживу, не получается, это переходит в болтовню. Спасибо за внимание. Всем удачи. Тебе, Игорь, отдельно. Нас ведь не забудут? Может даже прочитают от начала до конца))
← →
Внук © (2006-04-20 15:40) [396]>>xayam © (20.04.06 15:35) [395]
Конечно не забудут. За Вами придут :))
← →
Игорь Шевченко © (2006-04-20 15:41) [397]xayam © (20.04.06 15:35) [395]
> Тебе, Игорь, отдельно
Спасибо, взаимно!
← →
vovnuke © (2006-04-20 15:42) [398]
> [393] Игорь Шевченко © (20.04.06 15:28)
> с базой работают не сколько пользователи, сколько программы.
Под пользователем базы данных я понимаю не "конечного пользователя", а того кто (или что) непосредственно использует базу (ну конечно для достижения определенных целей необходимых для "конечного пользователя").
> Перегрузка ЧЕГО
Перегрузка функций, которые выполняют те или иные атрибуты. см. [391].
> для обеспечения уникальности уникальных значений
не так, а для разделения смысловой нагрузки, выполняемый тем или иным полем.
← →
Суслик © (2006-04-20 15:45) [399]2Игорь
> Перегрузка ЧЕГО ? Пользователей, базы, программы ? О какой
> перегрузке идет речь и почему не идет речь о перегрузке,
> когда согласно канонам требуется вводить дополнительные
> поля для обеспечения уникальности уникальных значений ?
Дай я попробую объяснить.
ДОпустим у тебя есть в БД только одна таблица. Тогда, действительно, можно обойтись без СК - взять ЕК (если найдется такое поле).
Представь, что у тебя в БД 10^3 таблиц (бывает же такое - спорить не будешь?). Есть таблица - справочник чего-то с ключем - ИНН. На эту таблицу по FK ссылаются 10^2 таблиц (такое же тоже бывает - спорить не будешь?). ИНН это скорее всего число 8 байт (вряд ли 4, т.к. столько там знаков 10 кажется?). Получается, что в таблицах, которые ссылаются на свой справочник будут тратиться лишние 4 байта на каждую ссылку. Это ли не перегрузака? Тут вряд ли можно поспорить. Если можно, то объясни :)
Да, ты можель возразить, что видите ли твои ISO это всего 3 знака. Ну хорошо. Можем и на это заложиться. Т.е. здесь вроде как перегрузки нет, если будем использовать ЕК на основе кода ISO.
В этом случае приведу тебе пример. Ты помнишь, что было с автономерами, вернее кодами регионов? Сначала было 2 цифры (77, 99), потом стало 3 (177). Сам понимаешь, что если бы ты для региона заложился на 1 байт (т.е. 256 максимум) то сейчас бы ты был в ..., ну т.е. пришлось бы много чего менять.
А у тебя есть уверенность в том, что через год коды ISO не станут строками? Ну например, распадется какая нить республика на 10^2 стран и для того, чтобы не плодить новых номеров из назовут примерно так - 055а, 055б и т.д.
Вот к чему я веду - оно тебе надо думать над такими проблемами (а что будет, а надежен ли такой ключ и пр.), если есть проверенное и ВСЕГДА работающее решение - СК?
← →
vovnuke © (2006-04-20 15:49) [400]
> [394] euru © (20.04.06 15:34)
Ну, значит я несколько отстал? Или, действительно, данную систему реально адаптировали под Россию.
Присоединяюсь к
> [395] xayam © (20.04.06 15:35)
Но если есть еще что сказать по существу, то с удовольствием послушаю.
← →
Хозяин (2006-04-20 15:55) [401]ответ по теме был дан еще в [12]
:)
← →
euru © (2006-04-20 16:01) [402]
> xayam © (20.04.06 15:21) [392]
> А словарь данных это по Вашей терминологии что?
Ну, например:
"Словарь данных – это база данных о данных и о структуре баз данных. Словарь данных включает каталог всех элементов данных, содержащих их имена, структуру и информацию об их использовании. Обычно словари данных конструируют для того, чтобы хранить ограниченное множество возможных метаданных, специализирующихся на информации, относящейся к элементам данных, базам данных, файлам и встроенным в систему программам." (http://glossary.basegroup.ru/s/DataDictionary.htm)
← →
Игорь Шевченко © (2006-04-20 16:05) [403]Суслик © (20.04.06 15:45) [399]
Я тебе еще раз объясняю - у меня база не варится сама в себе. Она взаимодействует с внешними источниками. Если стандарт изменится, он изменится для всех. И еще раз - стандарты не меняются, старые остаются, а новые появляются. В ISO, поверь, не дураки работают.
> Представь, что у тебя в БД 10^3 таблиц (бывает же такое
> - спорить не будешь?). Есть таблица - справочник чего-то
> с ключем - ИНН. На эту таблицу по FK ссылаются 10^2 таблиц
> (такое же тоже бывает - спорить не будешь?). ИНН это скорее
> всего число 8 байт (вряд ли 4, т.к. столько там знаков 10
> кажется?). Получается, что в таблицах, которые ссылаются
> на свой справочник будут тратиться лишние 4 байта на каждую
> ссылку. Это ли не перегрузака? Тут вряд ли можно поспорить.
> Если можно, то объясни :)
Все в этой жизни бывает. Ты только учти, что ROWID у Oracle, например, тоже не четыре байта, и ничего, живет себе. Про то, как байты тратятся, это совершенно отдельная история, и способов потратить байты в базе данных есть гораздо больше, чем ключи большого размера.
> В этом случае приведу тебе пример. Ты помнишь, что было
> с автономерами, вернее кодами регионов? Сначала было 2 цифры
> (77, 99), потом стало 3 (177). Сам понимаешь, что если бы
> ты для региона заложился на 1 байт (т.е. 256 максимум) то
> сейчас бы ты был в ..., ну т.е. пришлось бы много чего менять.
>
А если бы я не заложился, то и менять бы ничего не пришлось, верно ? Слишком много ложных предположений в твоей фразе.
← →
Суслик © (2006-04-20 16:18) [404]
> [403] Игорь Шевченко © (20.04.06 16:05)
> И еще раз - стандарты не меняются, старые остаются, а новые
> появляются. В ISO, поверь, не дураки работают.
верить в этой жизни нельзя никому.
Откуда дровишки про "не дураков"?
← →
Игорь Шевченко © (2006-04-20 16:27) [405]Суслик © (20.04.06 16:18) [404]
> Откуда дровишки про "не дураков"?
Отсюда: http://www.iso.org/iso/en/ISOOnline.frontpage
> верить в этой жизни нельзя никому.
А я не верю. Я с внешними источниками взаимодействую, получаю от них данных, отправляю им данные. Все хорошо.
← →
Lamer@fools.ua © (2006-04-21 09:37) [406]>>Игорь Шевченко © (20.04.06 01:18) [341]
Моё мнение в данный момент такое. Я заочно считаю, что СК лучше ЕК для любой системы, пока лично не столкнусь с такой системой, для которой сделаю вывод, что это не так.
Вот такой вот я упёртый :-)
← →
Игорь Шевченко © (2006-04-21 16:39) [407]Lamer@fools.ua © (21.04.06 09:37) [406]
Мой пример не убедительный ? :)
← →
Lamer@fools.ua © (2006-04-21 18:08) [408]>Мой пример не убедительный ? :)
Не-а. Я ж полного ТЗ не видел :-)
← →
xayam © (2006-04-21 22:26) [409]
> Не-а. Я ж полного ТЗ не видел :-)
это секрет, он не скажет
← →
Lamer@fools.ua © (2006-04-21 22:41) [410]>>xayam © (21.04.06 22:26) [409]
У к Вам небольшая просьба: пользуйтесь, пожалуйста, телепатором в тематических конференциях. Здесь он ни к чему. Полагаю, Игорь и сам сможет ответить. Без уполномоченных.
← →
xayam © (2006-04-21 22:48) [411]
> Lamer@fools.ua © (21.04.06 22:41) [410]
ну если к 410 сообщению не смог, то уже вряд ли. Но это по-моим меркам. А так конечно САМ ОТВЕТИТ
← →
Sergey Masloff (2006-04-21 22:54) [412]Все же проявлю гнусную настойчивость.
Утверждается что возникала ситуация когда страны в справочнике ISO (и в ОКСМ что еще важнее) а страна таки была и нужно ее было отображать в обмене документами с партнерами. Это вышеупомянутая мной Сербия и Черногория. А партнеры как раз такие что почти уверен - Игорю с ними приходится данными меняться. Так что проблема была близка...
Хотя тоже не проблема вобщем - то, можно было завести флаг выверенная - невыверенная и придумать свой код для обмена оставаясь в рамках ЕК.
← →
Игорь Шевченко © (2006-04-21 23:06) [413]Sergey Masloff (21.04.06 22:54) [412]
И каким образом здесь поможет неестественный ключ ?
> Игорю с ними приходится данными меняться
Разумеется. Но в ISO попадают государства с момента их официального образования, насколько мне известно, а на момент, пока их нет, можно использовать страну Югославию. И ничего. С валютами же разобрались, с SUR, RUR и RUB. И ничего, каждая валюта стала на свое законное место, а с валютами важнее, чем со странами.
Lamer@fools.ua © (21.04.06 22:41) [410]
Да ТЗ оно простое - самолетики летают по всему миру ну и мы к ним некоторым образом относимся.
← →
Sergey Masloff (2006-04-21 23:20) [414]Игорь Шевченко © (21.04.06 23:06) [413]
да я ж сам ответил - решение введение записи со статусом невыверено но и в твоем случае возможно тоже самое. Так что вобщем-то ничем.
>Но в ISO попадают государства с момента их официального образования, >насколько мне известно, а на момент, пока их нет, можно использовать >страну Югославию
Не совсем. Есть у них дельта. А вот насчет можно использовать страну югославию это совсем не так. Государство уже было и посольство уже было и Амад... тьфу партнеру печатающему по ряду причин наши документы нужно было печатать именно эту страну а то посольство с такими документами посылало... в Югославию ;-)
← →
Игорь Шевченко © (2006-04-21 23:41) [415]Sergey Masloff (21.04.06 23:20) [414]
> Государство уже было и посольство уже было и Амад... тьфу
> партнеру печатающему по ряду причин наши документы нужно
> было печатать именно эту страну а то посольство с такими
> документами посылало... в Югославию ;-)
Это все понятно, опять же, но как бы помогли искусственные ключи ? :)
← →
Sergey Masloff (2006-04-21 23:45) [416]Игорь Шевченко © (21.04.06 23:41) [415]
Да вобщем-то я и написал что никак. Я про то что ISO не является непогрешимым ;-)
← →
xayam © (2006-04-21 23:51) [417]
> euru © (20.04.06 14:59) [387]
> ... Словарь данных и структура БД- это две большие разницы...
О чем я по-твоему говорю всю эту ветку? Что данные (или словарь данных) и структура это две ОГРОМНЫЕ разницы, настолько огромные, что их надо разделить (сказал он в 101 раз, все еще надеясь, что его услышат). И разделить - не значит, что их надо вынести в другую базу (под названием ISO), где Вы не можете(если это не так - научите меня)контролировать изменения...
> euru © (20.04.06 16:01) [402]
> "Словарь данных – это база данных о данных и о структуре
> баз данных. Словарь данных включает каталог всех элементов
> данных, содержащих их имена, структуру и информацию об их
> использовании. Обычно словари данных конструируют для того,
> чтобы хранить ограниченное множество возможных метаданных,
> специализирующихся на информации, относящейся к элементам
> данных, базам данных, файлам и встроенным в систему программам."
Блин ну если бы так все писали, то вряд ли кто-нибудь что-нибудь понял
← →
Игорь Шевченко © (2006-04-21 23:57) [418]xayam © (21.04.06 23:51) [417]
> Блин ну если бы так все писали, то вряд ли кто-нибудь что-
> нибудь понял
Вообще-то все правильно написано, не вижу ничего непонятного.
← →
xayam © (2006-04-22 00:09) [419]
> Игорь Шевченко © (21.04.06 23:57) [418]
> Вообще-то все правильно написано
Может быть, если все понятно, а если нет, то как бы объяснить надо. Объяснить или можно другими словами сказать, которые по-проще выражают основную мысль. Вот за что мне Кодд и нравиться, несмотря на общность его правил, они выражают основную мысль.
Кстати насчет Кодда
> Игорь Шевченко © (20.04.06 15:28) [393]
> А я понимаю буквально, как написано.
Буквально там не понять. Написано то в общем. А на твоем примере его слова как-нибудь отражаются?
← →
Игорь Шевченко © (2006-04-22 00:20) [420]xayam © (22.04.06 00:09) [419]
> Может быть, если все понятно, а если нет, то как бы объяснить
> надо. Объяснить или можно другими словами сказать, которые
> по-проще выражают основную мысль
Можно сказать другим словом - метаданные. Куда как проще.
> А на твоем примере его слова как-нибудь отражаются?
Слова о том, что программа не должна зависеть от логических ограничений ?
А какой пример имеется в виду ?
← →
xayam © (2006-04-22 00:24) [421]
> Игорь Шевченко © (22.04.06 00:20) [420]
> Игорь Шевченко © (20.04.06 10:57) [353]
> xayam © (20.04.06 10:54) [352]
>
> Я говорю о том, что код ISO используется в качестве первичного
> ключа в таблицах, описывающих географические понятия, и
> в качестве поля для связки.
← →
xayam © (2006-04-22 00:26) [422]
> Слова о том, что программа не должна зависеть от логических
> ограничений ?
Не только, желательно каждое правило с 9 по 11
Страницы: 1 2 3 4 5 6 7 8 9
10 11 вся ветка
Форум: "Прочее";
Текущий архив: 2006.05.21;
Скачать: [xml.tar.bz2];
Память: 1.88 MB
Время: 0.024 c
