Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
> Атомарнось атрибутов - понятие не абсолютное, а относительное. Поделитесь источником этого умозаключения, pls. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2005, 15:51 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
FrankieЧто такое предопределенные запросы? Те, которые очевидны на этапе проектирования? В общем, да. FrankieИ почему LIKE это неверно? Потому, что LIKE почти всегда свидетельствует именно о нарушении 1NF. Бывают исключения, но это обычно ad hoc запросы. FrankieНе согласен, LIKE - мощная штука, глупо её игнорировать. Знаете, хорошие фундаментальные знания - еще более мощная штука. Но ведь "мы простых путей не ищем", да? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2005, 16:09 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
Frankie Что такое предопределенные запросы? Те, которые очевидны на этапе проектирования? И почему LIKE это неверно? Не согласен, LIKE - мощная штука, глупо её игнорировать. 1. предопределенные - это те запросы для которых БД разрабатывается :-) 2. LIKE - ужасно тормознутая и прожорливая штука. И поэтому ИМХО ее использовать надо лишь тогда когда ничего не помогает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2005, 16:11 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
mirЗнаете, хорошие фундаментальные знания - еще более мощная штука. Но ведь "мы простых путей не ищем", да? Что-то типа того. Разбивать чуть что на столбцы - большого ума не надо. mir, Вы не ответили на очень важный вопрос с этим связанный. Повторю: авторДаже если (часть значения столбца будет использоваться) всего 1-2 раза? Вы утверждаете, что необходимо расщеплять, если есть вероятность использования части значения столбца? А пока что ваше mirПотому, что LIKE почти всегда свидетельствует именно о нарушении 1NF. Бывают исключения, но это обычно ad hoc запросы. выглядит крайне неубедительно. Могу объяснить почему. А что такое "ad hoc запросы" я не знаю. Может дело в них? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2005, 16:24 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
А начальник не хочет поступиться принципами ввести в "поле, в идеале integer" хотя бы еще пару разрядов для хранения ID базы? На тему "умных" (интеллектуальных) ключей что-то писал Джо Селко (Joe Celko). Например, пин-код жителя города из реестра Главное - обеспечить неизменность ключа, чтобы избежать проблем с обновлениями. guest_20040621> Атомарнось атрибутов - понятие не абсолютное, а относительное. Поделитесь источником этого умозаключения, pls. Атомарность определяется рамками моделируемой предметной области. Если вы делаете CRM, то телефон контактной персоны атомарен. Если делаете учет кабельного хозяйства телефонной сети, то неатомарен (первые три цифры - номер АТС, далее номер шлейфа). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2005, 17:13 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
> Атомарность определяется рамками моделируемой предметной области. Я просил назвать источник этого умозаключения. Надеюсь, это не слишком обременяющая просьба? > Если вы делаете CRM, то телефон контактной персоны атомарен. > Если делаете учет кабельного хозяйства телефонной сети, то неатомарен (первые > три цифры - номер АТС, далее номер шлейфа). Что общего между "телефоном контактной персоны" и "кабельным хозяйством телефонной сети", позвольте поинтересоваться? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2005, 18:42 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
E. F. Codd ACM Transactions on Database Systems, Vol. 4, No. 4, December 1979. p 410 The need for unique and permanent identifiers for database entities such as employees, suppliers, parts, etc., is clear. User-defined and user-controlled primary keys in the relational model were originally intended for this purpose. There are three difficulites in employing user-controlled keys as permanent surrogates for entities. (1) The actual values of user-controlled keys are determined by users and must therefore be subject to change by them (e.g., if two companies merge, the two employee databases might be combined with the result that some or all of the serial numbers might be changed). (2) Two relations may have user-controlled keys defined on distinct domains (e.g., one uses social security, while the other uses employee serial number) and yet the entities denoted are the same. (3) It may be necessary to carry information about an entity either before it has been assigned a user-controlled key value or after it has ceased to have one (e.g., an applicant for a job and a retiree). А LIKE всякий бывает, и хороший: Код: plaintext Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2005, 18:43 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
Кажется автор темы имел в виду тот like оторый "не очень" :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2005, 19:53 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Атомарность определяется рамками моделируемой предметной области. Я просил назвать источник этого умозаключения. Надеюсь, это не слишком обременяющая просьба? Обременяющая :) Считайте, что из головы. Если есть возражения - вперед. Нет - в сторону :) > Если вы делаете CRM, то телефон контактной персоны атомарен. > Если делаете учет кабельного хозяйства телефонной сети, то неатомарен (первые > три цифры - номер АТС, далее номер шлейфа). Что общего между "телефоном контактной персоны" и "кабельным хозяйством телефонной сети", позвольте поинтересоваться? Очевидно, атрибут "номер телефона". Атомарный в первом случае и неатомарный во втором. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2005, 19:55 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
> Считайте, что из головы. Понятно. Тогда это просто ошибочная точка зрения. > Очевидно, атрибут "номер телефона". Т. е. Вы полагаете, что "номер шлейфа + АТС" эквивалентно "телефонный номер"? А если это оператор мобильной связи? а если IP-телефон? IRIDIUM? ;) Получается, что атомарность идентификатора (телефонный номер - просто некоторый идентификатор) зависит от способа связи? ;)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2005, 22:50 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
prof79Кажется автор темы имел в виду тот like оторый "не очень" :-) Никакого конкретного LIKE я не имел ввиду. Transact-SQL предоставляет очень широкие возможности по его использованию. В моём примере речь идёт скорее о сравнении по какой-то части ключа вроде Код: plaintext 2 Templar & guest_20040621. Вот как раз в случае с телефонами моё предложение как нельзя актуально. Я бы ни в коем случае не дробил телефонный номер! Городской, федеральный сотовый, прямой московский сотовый, междугородний... Я не понимаю, что сложно написать распознающую структуру что ли??? А споры, в общем, ведутся вокруг того расщеплять или нет. Что расщеплять? на сколько атомов? Даже если вы найдёте решение у вас получится набор столбцов, большинство из которых хранят пустые значения (или умолчания) практически во всех записях. В боле общем понимании суть состоит в том, как оптимально разбить на атомы. Я надеюсь, что господин mir выскажется по этому поводу. Большинство из здесь пишущих, судя по всему, придерживается правила "не уверен - расщепляй" , видимо потому, что синтез в данном случае и проще и быстрее, чем анализ. Повторюсь, но мне кажется что не надо быть 7 пядей во лбу, чтобы фигачить по такому принципу логическую модель БД (таблицы и связи). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2005, 23:55 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
guest_20040621Т. е. Вы полагаете, что "номер шлейфа + АТС" эквивалентно "телефонный номер"? Я полагаю, что вы занимаетесь передергиваниями. "номер шлейфа + АТС" это номер абонента городской телефонной сети. Можете проверить, набрав его на своем телефоне. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2005, 00:00 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
Frankie Никакого конкретного LIKE я не имел ввиду. Transact-SQL предоставляет очень широкие возможности по его использованию. В моём примере речь идёт скорее о сравнении по какой-то части ключа вроде Код: plaintext Frankieно мне кажется что не надо быть 7 пядей во лбу, чтобы фигачить по такому принципу логическую модель БД (таблицы и связи).Конечно нет, надо быть семи пядей во лбу, чтобы сделать так, как считаете Вы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2005, 00:25 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
> Я полагаю, что вы занимаетесь передергиваниями. Перечитайте Ваш [1480394]. Никаких передергиваний. Вы делаете распространенную ошибку. Есть идентификаторы (суть естественные ключи; как и все естественные ключи, они вполне могут быть уникальны если а) уникальны их регистранты, б) правила формирования могут быть формализованы и описаны). Они не зависят (или мало зависят) от предметной области. Когда Вы говорите о "кабельном хозяйстве телефонной сети", то на самом деле описываете технологию формирования такого идентификатора. Т. е. одним из результатов Вашего описания будет телефонный номер. ;) Собственно номер - набор цифр - не зависит ни от предметной области, ни от степени детализации. ;)) Ы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2005, 00:32 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
> Вот как раз в случае с телефонами моё предложение как нельзя актуально. Абсолютно неактуально. > Даже если вы найдёте решение у вас получится набор столбцов, большинство из > которых хранят пустые значения (или умолчания) практически во всех записях. У-у-у... дружище, начните, наконец, _изучать_ проектирование баз данных. Купите книжку, что-ли? Или репетитора наймите. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2005, 00:41 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
guest_20040621 Вы о чем, собсно, рассуждаете, об иденитфикаторах? А я об атомарности атрибутов, необязательно ключевых. Ага. Раз с телефонами так сложно получается, то возьмите пример попроще, с "ФИО". Где-то нужно хранить три атрибута, где-то - одну строку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2005, 00:43 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
> Вы о чем, собсно, рассуждаете, об иденитфикаторах? > А я об атомарности атрибутов, необязательно ключевых. Очень хороший, правильно заданный вопрос. ;) И я о них же. Среди атрибутов очень много таких, которые на самом деле идентификаторы. ;)) Которые, конечно, абсолютно необязательно ключевые. Опыт показывает, что такие атрибуты правильнее описывать совершенно определенным образом (версионность, история изменений). И опыт показывает, что атомарность таких атрибутов не зависит (или мало зависит) от предметной области. Т. е. никакой "относительностью" не пахнет. ;)) Собственно, это ровно противоположное Вашему тезису утверждение. ;) > Раз с телефонами так сложно получается, то возьмите пример попроще, с "ФИО". У-у-у... напрасно Вы так. Этот пример еще хуже. ;)) > Где-то нужно хранить три атрибута, где-то - одну строку. Фамилия, имя, отчество - суть естественный идентификатор. ;)) Не буду повторять все, что говорил по этому поводу, сразу вывод, если позволите: нет задачи, для которой можно было бы хранить фамилию, имя, отчество одной строкой. Если Вы видите такую реализацию, можете быть уверены в том, что базу данных проектировал абсолютно далекий от проектирования человек. Дейта в глаза не видевший. ;)) Ну, или задача типа записной книжки для мобильного телефона. ;)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2005, 01:48 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
guest_20040621Фамилия, имя, отчество - суть естественный идентификатор. ;)) Не буду повторять все, что говорил по этому поводу, сразу вывод, если позволите: нет задачи, для которой можно было бы хранить фамилию, имя, отчество одной строкой. Если Вы видите такую реализацию, можете быть уверены в том, что базу данных проектировал абсолютно далекий от проектирования человек. Дейта в глаза не видевший. ;)) Ну, или задача типа записной книжки для мобильного телефона. ;)) Почтовая система в качестве примера подойдет? Не слишком простая? Вот ведь незадача, не учитывает людей, учитывает адресаты. А потому ФИО всего лишь атомарный атрибут адресата, причем необязательный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2005, 02:20 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
> Почтовая система в качестве примера подойдет? Не слишком простая? ;) Я не телепат. Не сталкивался со структурой данных почтовых систем. > Вот ведь незадача, не учитывает людей, учитывает адресаты. А потому ФИО всего > лишь атомарный атрибут адресата, причем необязательный. Хех, ну и при чем здесь ФИО? Если письмо будет адресовано "жирному ублюдку, который плохо пахнет", а адрес при этом будет правильным, такое письмо дойдет? ;)) Так о чем речь-то? В Вашем изложении речь идет именно об атрибуте адресата, _в общем случае не обязанным иметь ничего общего с фамилией, именем и отчеством_. ;)) Это Вы почему-то решили, что этот атрибут должен быть обязательно ФИО. Я понимаю, что Вы хотели проиллюстрировать этим примером. ОК, давайте чуть расширим наше представление об идентификаторах, которые мы используем как атрибуты. В общем случае они могут иметь суффиксы, префиксы и псевдонимы (алиасы или как Вам удобнее). Ваш пример - хороший пример использования алиасов. ;)) Аналогичный пример с телефонным номером: можно записать его буквами, а не цифрами. Буквенное обозначение - тоже псевдоним. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2005, 02:50 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
guest_20040621 Телефон не годится, ФИО не нравится... Третий и последний раз. Артикул товара по каталогу производителя. У поставщика - неатомарный, составной на основе классификации. У покупателя-дистрибутора своя классификация, артикул поставщика атомарен, идет как внешняя ссылка. Это атрибут одной и той же сущности - товарной позиции. Свой артикул также может быть атомарен в схеме БД, несмотря на то, что различные его части (и цифровые и буквенные - ограничено полетом фантазии) имеют свой смысл. На сем предлагаю переливания из пустого в порожнее завершить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2005, 03:06 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
guest_20040621 MirАтомарность атрибутов - понятие не абсолютное, а относительное. Поделитесь источником этого умозаключения, pls. Поделюсь, поделюсь. Хотя вам вполне ясно ответили: TemplarАтомарность определяется рамками моделируемой предметной области. Вы дали просто потрясающий ответ: guest_20040621Понятно. Тогда это просто ошибочная точка зрения. То есть мы вам обязаны что-то обосновывать, а вы нам нет. Типа точку поставили в споре. Такой Большой Папа, мнение которого правильно по определению. Между тем, вам бы с базовыми знаниями определиться. Например: guest_20040621Среди атрибутов очень много таких, которые на самом деле идентификаторы. ;)) Которые, конечно, абсолютно необязательно ключевые. То есть вы противопоставляете потенциальные ключи (ключевые атрибуты) и атрибуты идентификаторы? Большего бреда я в жизни не видел. К вашему сведению, ключевые атрибуты и атрибуты-идентификаторы — это одно и то же. Если только вы не имели в виду что-то совсем иное (вроде «ключевые» относится только к первичному ключу, но не обязательно к потенциальному ключу). В противном случае хотелось бы выслушать развернутую аргументацию по обоснованию вашего «открытия». Далее: guest_20040621Опыт показывает, что такие атрибуты правильнее описывать совершенно определенным образом (версионность, история изменений). И опыт показывает, что атомарность таких атрибутов не зависит (или мало зависит) от предметной области. Т. е. никакой "относительностью" не пахнет. ;)) То есть у вас «опыт», и он что-то там «показывает». Это очень сильный аргумент в споре. Прям наповал. Конечно же, ни у кого больше никакого опыта по определению быть не может (Большой Папа, помним, помним). Однако здесь заметно вот что. И я, и Templar рассуждали об атрибутах вообще, т.е. об общем случае. Вне зависимости от их принадлежности к потенциальным ключам. Вы же рассуждаете только о частных случаях: *такие* атрибуты, атомарность *таких* атрибутов, *мало* зависит. И что значит «мало» зависит? Если зависит, что ж вы спорите? Если не зависит, при чем здесь «мало»? Это как быть «слегка беременной». Ну а теперь я все же объясню, почему атомарность атрибутов отношений БД относительна, а не абсолютна. 1. Реальному миру атомарность не присуща. Если бы вы изучали системологию, то знали бы, что одним из главных постулатов теории систем является утверждение о том, что каждый элемент системы в свою очередь является системой. И так до бесконечности. Древние придумали понятие атома, неделимого элемента материи, но его давно уже разложили на элементарные частицы, а те не субчастицы и т.д. 2. Таким образом, идеальная модель реального мира должна обладать бесконечным уровнем детальности. 3. Реальные модели всегда являются «огрублением» моделируемой системы. Они сознательно игнорируют те или иные аспекты оригинала, неважные для цели моделирования. И они всегда рассматривают оригинал на том или ином уровне детальности. Это еще один постулат системологии. 4. Важный аспект моделирования — его цель. Поскольку модель есть артефакт, искусственная конструкция, заведомо упрощающая оригинал в том или ином аспекте, должна быть предопределена цель такого упрощения. Любая модель всегда создается в условиях заведомо известных и заранее выбранных ограничениях, направленных на достижение заданной цели. Если цель будет иной, то и модель той же самой системы-оригинала будет создана иной. Возможно, кардинально иной. 5. База данных в конечном итоге является моделью реального мира. Еще точнее можно сказать, что моделью «части» реального мира, или «одной из моделей», но это неважно. 6. База данных создается как упрощение реального мира, как и любая модель. 7. Создание базы данных всегда преследует определенную цель, задающую соответствующие ограничения, в том числе уровень детальности моделирования. 8. Таким образом атомарность атрибутов БД полностью определяется выбранным уровнем детальности моделирования, который в свою очередь полностью определяется конкретной целью создания БД. 9. Таким образом, атомарность атрибутов БД есть понятие не абсолютное, а относительное. Почитайте, к примеру, классическую книгу Флейшман Б.С. Основы системологии. — М.: Радио и связь, 1982. — 368 с. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2005, 08:25 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
> Телефон не годится, ФИО не нравится... Да мне-то как раз нравится. Только Ваши примеры как-то не слишком иллюстрируют полезность Вашего подхода. Скорее наоборот. ;)) > Артикул товара по каталогу производителя. У-у-у... все плохо. Снова бесполезный пример, абсолютно аналогичный уже рассмотренным. Аргументы закончились, я так понимаю? ;)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2005, 08:33 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
Frankie softwarerЭто, простите, в музей юмора. Сходите в гугль и почитайте, что такое суррогатный ключ. Я знаю, что это такое. Если бы я говорил о естественном, то сразу бы сделал 3 столбца и определил их ключевыми. Тогда, если Вас не затруднит, опубликуйте пожалуйста определение, которое Вы знаете - что есть суррогатный ключ. Желательно вместе с источником, где Вы его нашли. Frankie"точка зрения сервера" означает сохраность уникальности значений столбца. Хм. Приведите, пожалуйста, определение 1НФ, где фигурировала бы "уникальность значений столбца". FrankieДанное поле анализируется только когда это необходимо. Shtock привёл крайность, я же прекрасно понимаю, что стоит за таким применением. Вы не понимаете другого - что именно эту крайность Вы и пропагандируете, пусть в скромном объеме. FrankieОбъединение столбцов в моём примере как нельзя логично. Хм. Если сравнить это с Вашим изначальным письмом - складываете впечатление, что Вы твердо рассчитывали услышать "Вы правы, а Ваш начальник - не прав". Не услышите, по крайней мере не более чем в исчезающе малом проценте высказываний. FrankieКстати будет ответить Shtock'у следующим: "давайте сразу создавать таблицы с огромным числом столбцов длины, скажем, 3. Конкатенация это же так просто!" Это действительно будет кстати - аболютно аналогично Вашему подходу. Поясняю: Теория, равно как и Shtock, полагают правильным создавать столбцы, значения которых применяются в операциях с минимальным количеством дополнительных операций. Взять значение - и все. Вы предлагаете делать "большой" столбец и при каждой операции расщеплять его. Потом - предлагаете делать "маленькие" столбцы и при каждой операции соединять их. Это именно что два одинаково неудобных подхода, в то время как оптимум - атомарные значения. FrankieПо поводу "выковыривания данных". Во-первых, на основе такой таблицы создаётся представление, в котором ключ расщеплён. Итак, вместо одного объекта делаем минимум два. Плюс - пара триггеров instead of, чтобы собирать это значение. Эффективностью на таких объемах пренебрегаем без проблем. В итоге. В итоге, вместо "создания лишнего поля" Вы создаете лишнее представление. Интересное представление об экономии :) Оккам посмеялся бы. FrankieВо-вторых, "выковыриванием" занимается чаще всего приложение, где это сделать совсем уж не проблема. То есть вдобавок имеем смешивание функций сервера и клиента. Следующий шаг - перенос логики на клиента; в самом деле, логику-то надо писать с удобными для оперирования значениями. FrankieИ ещё. 15,000 записей - это вся Формула-1 за 55 полных сезонов. Так что 15,000,000 даже для чемпионата NASCAR, где проводилось в среднем по 40 этапов с 40 участниками на каждом, 1 миллион, не то что 15 - это за гранью разумного. Дык - никто не спорит с тем, что эта задача будет работать, как бы страшно ее ни реализовать. Но в связи с этим веселят Ваши упоминания убогого MySQL. FrankieЯ долго размышлял над вопросом: вот есть гонщик - "имя фамилия". Но ведь можно расщепить на имя+фамилия? Что это даст? "Можно расщепить" не имеет отношения к атомарным значениям. Их, кстати, правильнее было бы назвать "молекулярными" - помните, "мельчайшая частица.. сохраняющая все свойства". Расщеплять имя-фамилию нужно, если в одном контексте употребляется "Имя Фамилия", в другом - "И. Фамилия", в третьем - "ФАМИ". Если везде употребляется одна и та же связка - атомарное значение и есть. FrankieСкажу ещё кое-что. Раз для всех вас мой спобос - грубая, явная ошибка, то остаётся ещё раз удивится недалёкости наших преподавателей. Ведь эта система является, ни много ни мало, моим бакалаврским дипломом, на отлично защищённым ;) Хм. Примерно пол-года назад я в одной книге, написанной преподавателями не последнего питерского ВУЗа, нашел утверждение, прямо противоречащее одной из оcновных теорем нашей с Вами науки. А Вы хотите, чтобы они заглянули, что Вы там у себя понаписали. Простите, помимо прочего, сколько из них видело Ваш диплом дальше обложки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2005, 12:34 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
FrankieИ почему LIKE это неверно? Не согласен, LIKE - мощная штука, глупо её игнорировать. Как Вам сказать.. Атомная бомба - мощная штука, глупо ее игнорировать. Но для большинства прикладных задач - например, обшмонать рынок - я бы у нашей доблестной милиции и огнестрел бы отбирал. Слишком неудачные побочные эффекты. Повторюсь: задача на 15.000 записей будет нормально работать даже на i386, как бы ее ни написать. Но, если я правильно понимаю, сейчас Вы от своего диплома переходите к реальной работе, где эта логика теряет свою силу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2005, 12:42 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
> То есть мы вам обязаны что-то обосновывать, а вы нам нет. Я свои аргументы привел. А вот с ответными аргументами - как-то глуховато. ;) > То есть вы противопоставляете потенциальные ключи (ключевые атрибуты) и > атрибуты идентификаторы? Вы читаете или излагаете вместо меня? Если вместо, не буду мешать. Если читаете - читайте внимательнее. > То есть у вас «опыт», и он что-то там «показывает». Это очень сильный > аргумент в споре. ;)) Дружище, у меня нет времени описывать всю последовательность рассуждений. Это долго и нудно. Придется начинать со стандартов, метаданных, тезауруса и пр. Это не на пару абзацев и не на пятнадцать минут. Поэтому я предложил только выводы. По существу есть возражения? > Вы же рассуждаете только о частных случаях: ;) Эти частные случаи вполне себе иллюстрируют безосновательность и Ваших утверждений, и утверждений г-на Templar. > Еще точнее > можно сказать, что моделью «части» реального мира, или «одной из моделей», > но это неважно. Напротив, это крайне важно. Отметим, что модель данных [вообще говоря, любой базы данных] концептуальна, т. е. отражает представления разработчика этой структуры данных о предметной области. И я лично совсем не уверен, что эта модель сколь-нибудь адекватна в подавляющем большинстве случаев. ;) > Таким образом, атомарность атрибутов БД есть понятие не абсолютное, а > относительное. ;)) ОК, пара вопросов: берем простые распространенные атрибуты (телефонный номер; фамилию, имя, отчество человека; ip-адрес; номер ФИДО; e-mail (а лучше URI); название предприятия; идентификатор налогового учета (первое, что пришло в голову). Пожалуйста, продемонстрируйте, как будут меняться эти атрибуты (атомарность атрибутов) в зависимости от предметной области (пока не будем рассматривать специализированные структуры, где эти сущности выступали бы основным предметом описания). Опционально: как по-Вашему, для перечисленных атрибутов может существовать некая каноническая форма записи? P.S. Вы отметили, надеюсь, что я тактично проигнорировал Ваши хамские замечания и ответил исключительно по существу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2005, 13:09 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=33023595&tid=1545898]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
38ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
| others: | 236ms |
| total: | 365ms |

| 0 / 0 |
