Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
Павел, т.е. в таблице dogovor поле client_id не зависит от document_id? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2005, 15:56 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
нумерацию документов имелось в виду. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2005, 15:57 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
> Ладно, не знакомо, так незнакомо, проехали. Нет, не проехали. Какое определение Вы имели в виду? Каких систем и каких объектов? > Примеры были приведены для опровержения вашего "общего случая" > независимости атомарности от рамок рассматриваемой системы. Хех, ну х. з., кто с логикой дружит, а кто нет. Вы утверждали (и утверждаете, насколько я понял), что атомарность атрибутов относительна. Я утверждал (и утверждаю), что есть такие атрибуты, для которых это утверждение в общем случае неверно. Для обоснования своей точки зрения я использовал _приведенные Вами_ примеры, когда атрибуты, которые по-Вашему относительно атомарны, таковыми не являлись. Я никогда и нигде не писал, что атомарность _любых атрибутов_ абсолютна и неизменна. Читать-то Вы, надеюсь, умеете? Далее я просил (тАвАриСТЧА mir, правда, но это как бы неважно) показать, как будет меняться атомарность атрибутов (список в сообщении был) в зависимости от предметной области. Вместо ответа получил полную ахинею об атомарности времени (это просто прорыв в проектировании какой-то; наверное, навеяно _личным участием_ тАвАриСТЧА mir в разработке АСУ ТП). Что нелогично и где именно, по-Вашему? > Поэтому, чтобы не сойти за болтуна, потрудитесь таки обосновать свое общее > утверждение более весомыми утверждениями, чем "это очевидно". Не понимаю, какие еще обоснования Вам нужны. Что непонятно в написанном? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2005, 16:08 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
2 gardenman. Отлично! Мне действительно понравилось. Возможно это прозвучит странно, но другого решения такой задачи я и не видел. gardenmanкогда я что-то проектирую я менньше всего думаю о нормальных формах. Просто несколько принципов: Каждое значение атрибута должно появляться по возможности только 1 раз, в одной таблице и в одной строке. Количество объектов (индексы, таблицы и прочее) должно быть минимальным. Должна осуществляться жесткая поддержка ссылочной целостности. Подписываюсь под каждым словом :) А насчёт идентификации личности по "ФИО, дата и место рождения" - вообще неправильно. Во-первых, что такое место рождения? Роддом что ли? Во-вторых, бывают, знаете ли, полные тёзки, родившиеся в один день. А если у нас люди с разным гражданством и в документе ФИО (если есть О) написаны разным алфавитом? У арабов например вообще имена гигантские, а в корее очень много однофамильцев... Неее, "ФИО, дата и место рождения" это никак уж не гарантирует уникальности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2005, 16:53 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
2 guest_20040621 Да конечно мы несем ахинею, конечно, тактичный вы наш. Известно же, что помимо вас никто в принципе ничего не знает и знать не может. Вы, в общем-то поэтому и не обязаны стрго аргументировать свои взгляды. Это пусть другие пишут детальные посты. А вам можно просто сказать "Тогда это просто ошибочная точка зрения". И все. А если и этого мало, тогда добавить "У-у-у...". Такой аргумент уж точно никто не перешибет. А если серьезно, оспорьте любой из моих постов. С реальными возражениями. К сожалению, помним, что у вас "нет времени описывать всю последовательность рассуждений. Это долго и нудно". Конечно же, если бы время было, вы бы нас... С левой "стандартами", с правой "метаданными", контрольный в голову - "тезаурус". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2005, 16:58 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
авторОтлично! Мне действительно понравилось. Возможно это прозвучит странно, но другого решения такой задачи я и не видел. dogovor->pasport->klient выбрать договоры с указанием на нынешних фамилий клиентов и фамилий на момент заключения договора select dogovor.nn, pasport.fio (select top 1 fio from pasport pp where pasport.klient_id=pp.klient_id) as current_fio from dogovor join pasport on pasport.id=dogovor.pasport_id ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2005, 17:52 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
тьфу, дату забыл select dogovor.nn, pasport.fio (select top 1 fio from pasport pp where pasport.klient_id=pp.klient_id order by data_vidachi) as current_fio from dogovor join pasport on pasport.id=dogovor.pasport_id ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2005, 17:54 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
> А если серьезно, оспорьте любой из моих постов. С реальными возражениями. Легко. Например, Ваш пример со временем. Речь идет не об изменении атомарности, а о точности измерения и декомпозиции. Как у времени может меняться атомарность, если по сути это число + единица измерения + точка отсчета, поясните, пожалуйста? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2005, 18:35 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
FrankieНеее, "ФИО, дата и место рождения" это никак уж не гарантирует уникальности. C теоретической точки зрения Вы правы - и при учете населения используется, если не ошибаюсь, номер свидетельства о рождении. Но в то же время в практике госучреждений, в практике обработки плохих данных, импорта всяких ублюдочных dbf-ов, если не текстовых файлов - используется именно этот набор атрибутов. Хватает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2005, 18:39 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
guest_20040621Вы утверждали (и утверждаете, насколько я понял), что атомарность атрибутов относительна. Я утверждал (и утверждаю), что есть такие атрибуты, для которых это утверждение в общем случае неверно. Для обоснования своей точки зрения я использовал _приведенные Вами_ примеры, когда атрибуты, которые по-Вашему относительно атомарны, таковыми не являлись. Я никогда и нигде не писал, что атомарность _любых атрибутов_ абсолютна и неизменна. Читать-то Вы, надеюсь, умеете? Короче говоря, по-вашему "атомарность _любых атрибутов_ абсолютна и неизменна" - ложное утверждение. Согласен. Это означает, что по-вашему, существуют атрибуты, атомарность которых относительна. Осталось сделать шажок и объяснить, с какой стати атомапрность остальных атрибутов абсолютна. Ну, вот так их господь создал. Вырезал из гранита. Я потому и пытался вас навести на определение системы, как совкупности объектов (элементов) и их связей. Любая декомпозиция на элементы относительна. Если вы помните историю, то сам физический атом в начале считался эээ... атомарным :)) Но потом оказалось, что он тоже состоит из других элементов. Соответственно, любая ваша декомпозиция системы на сущности, связи и атрибуты также относительна цели моделирования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2005, 19:14 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
> Осталось сделать шажок и объяснить, с какой стати атомапрность остальных > атрибутов абсолютна. Хех, их абсолютность - штука тоже условная. ;) Попробую объяснить. [сильно упрощенно] Если атрибут может быть представлен в виде [грантор][сущность] + [идентификатор_грантора], такой атрибут будет атомарным для всех баз данных, исключая базы данных грантора. > Ну, вот так их господь создал. Вырезал из гранита. На самом деле это просто идентификаторы, которые некто/нечто раздает монопольно/условно монопольно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2005, 19:34 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
guest_20040621 [сильно упрощенно] Если атрибут может быть представлен в виде [грантор][сущность] + [идентификатор_грантора], такой атрибут будет атомарным для всех баз данных, исключая базы данных грантора. Что есть грантор? Надеюсь, не фонд Сороса ? На самом деле это просто идентификаторы, которые некто/нечто раздает монопольно/условно монопольно. Да забудьте вы про идентификаторы на время. Не плодите лишние сущности. В модели "сущность-связь" на верхнем уровне нет никаких идентификаторов. Они появятся позже, когда возникнет необходимость детализации в рамках реляционной модели. А если в рамках сетевой, например, так и не появятся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2005, 23:03 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
Изучайте логику. В частности т. Геделя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2005, 23:29 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
> Что есть грантор? Надеюсь, не фонд Сороса? [Публичный] генератор идентификаторов. > Да забудьте вы про идентификаторы на время. Не плодите лишние сущности. В > модели "сущность-связь" на верхнем уровне нет никаких идентификаторов. Они > появятся позже, когда возникнет необходимость детализации в рамках > реляционной модели. А если в рамках сетевой, например, так и не появятся. Вроде пока мы в рамках реляционной, так что ни о чем забывать не будем. ОК, попробуем по-другому. Есть достаточно большое количество реляционных баз данных. Представьте, что мы получили возможность описать эти базы данных в некоторой специально для этого созданной структуре. Окажется, что некоторые сущности часто выступают в роли атрибутов других сущностей, причем одинаковым образом (я упоминал стандарты, метаописание и тезаурус подразумевая именно задачу создания такой структуры). Более того, за пределами баз данных владельца базы данных, где они являются основным предметом описания, они везде будут выступать в одинаковой роли. Для практического применения нам даже не нужна структура баз данных этого владельца: существенную для нас часть (имя владельца базы данных (или группы владельцев, или условного владельца) и имя этой сущности) мы можем получить и не зная внутренней структуры. Попробую провести такую аналогию: представьте, что атрибут всегда принимает значения из строго определенной таблицы, заполненной некоторым генератором. Для практических задач не нужно знать правил работы генератора, достаточно знания факта, что все возможные значения атрибута находятся в строго определенной таблице. Какую бы сущность мы не описывали, рассматриваемый атрибут всегда будет принимать значения только из этой таблицы. Вот такие "однотабличные" атрибуты не будут относительно атомарными. ;) Примеры я приводил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2005, 00:04 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
guest_20040621ОК, попробуем по-другому. Требование атомарности напрямую следует из определения домена как потенциального множества значений простого типа данных, т.е. среди значений домена не могут содержаться множества значений (отношения). При этом сам домен - допустимое множество значений данного типа - определяется относительно моделируемой системы. Говоря о ваших "табличных" генераторах вы не замечаете (или не хотите замечать), что суть такого приема проста - вы искуственно вводите в систему(ы) домен (причины такого решения мы не рассматриваем). Этот домен, конечно, будет атомарен по определению. По вашему личному определению (пока не вырвется за рамки системы, подобно номерам паспортов или соцстраха). Вы сознательно вводите внемодельный артефакт. И пытаетесь на этой основе показать, что существуют (где за пределами вашей реализации?) сущности, атрибуты которых "абсолютно" атомарны :)) Теперь вернитесь к началу Атомарность атрибутов - понятие не абсолютное, а относительное. Вы пытаетесь опровергнуть это утверждение введением в сущность искусственных (служебных, системных) атрибутов, которые к тому же не выходят за рамки реализации конкретной системы(систем) :)) Предлагаю таки закруглиться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2005, 02:58 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
guest_20040621> А если серьезно, оспорьте любой из моих постов. С реальными возражениями. Легко. Например, Ваш пример со временем. Речь идет не об изменении атомарности, а о точности измерения и декомпозиции. Как у времени может меняться атомарность, если по сути это число + единица измерения + точка отсчета, поясните, пожалуйста? Вот это уже разговор. 1. Ваша мысль о том, что (упрощаю) речь идет не об изменении атомарности, а о декомпозиции, представляется мне странной и нелогичной. Что такое декомпозиция? По определению разложение, разбиение целого на составные части , то есть смена уровня детальности . То есть декомпозиция есть в точности изменение атомарности . Таким образом, ваша сентенция внутренне противоречива. 2. Теперь еще раз: время в реальном мире есть процесс непрерывный. Дискретизация времени — единственный способ иметь с ним дело в модели, но огрубление при этом неизбежно (по определению). Степень дискретизации и само представление такой характеристики как «момент наступления события» может быть разной и определяется целью создания модели (в нашем случае — базы данных). Об этом в точности я и говорил. То есть для частной задачи мы можем представить характеристику «момент наступления события» как атомарное значение типа DATE (представление) с точностью до дня (степень дискретизации). Пример: атрибут «дата рождения» в системе кадрового учета. Для другой частной задачи мы можем представить характеристику «момент наступления события» как совокупность атрибутов [Год: INT, Месяц: INT, День:INT, Время: TIME] (представление) с точность до миллисекунды (степень дискретизации). Пример: замеры с датчика в промышленной системе. Вывод: как детальность, так и способ представления информации о предметной области в общем случае не абсолютны, а относительны. Они определяются целью создания системы и ограничениями, налагаемыми на систему. Разумеется, никто не отрицает, что некоторые характеристики некоторых сущностей от системы к системе практически не меняют ни представление, ни детальность. Вес и рост человека обычно вещественное число, суррогатные первичные ключи всегда атомарны (хотя представление их меняется: то INT, то LONG INT, то GUID). Такие примеры есть. Тем не менее, я бы прокомментировал их наличие вовсе не тем, что общее правило «не работает», т.е. не является «общим». Тут другое. Возьмем «рост». Ничто не гарантирует, что не появится система, требующая «декомпозировать» рост человека на, к примеру, [«длина ног», «длина туловища», «длина шеи», «длина головы»]. То есть это вопрос потребности, а не принципа. Теперь возьмем суррогатные первичные ключи. Они пожалуй всегда будут атомарными. Однако не забудем, что они не «настоящие» характеристики. Это артефакты, искусственно создаваемые по искусственным правилам. Поэтому законы реального мира на них вообще слабо влияют. Поскольку вы сказали, что «Я никогда и нигде не писал, что атомарность _любых атрибутов_ абсолютна и неизменна», то по сути с высказанной мной точкой зрения согласны. Так и завершим спор, если спорить не о чем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2005, 07:13 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
> Предлагаю таки закруглиться. ОК. Пара пояснений. > Требование атомарности напрямую следует из определения домена как > потенциального множества значений простого типа данных, Принципиальная разница между доменом и приведенным примером. Публичные идентификаторы имеют определенного грантора и применимы исключительно к определенным сущностям. Иначе чего б я сразу не провел аналогию с доменами? > вы искуственно вводите в систему(ы) домен Ничего не ввожу. Я хочу показать Вам, что существуют формальные критерии определения условно абсолютных атрибутов. Кроме того, ничего более. > пока не вырвется за рамки системы, подобно номерам паспортов или > соцстраха Даже вне рамок системы номер паспорта _всегда_ будет оставаться номером паспорта. В любой предметной области. ;) > Вы пытаетесь опровергнуть это утверждение введением в сущность > искусственных (служебных, системных) атрибутов, которые к тому же не > выходят за рамки реализации конкретной системы(систем) :)) Это я настолько плохо излагаю или Вы невнимательно читаете? ;)) Я никуда не ввожу никаких новых артефактов. Просто показать существование абсолютных атрибутов вполне можно их перечислением. Хотелось решить другую задачу: предложить формальные критерии определения таких атрибутов. Безотносительно конкретной реализации. Получилось с переменным успехом. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2005, 10:40 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
mir, Вы полагаете, если я начну представлять вещественные числа в экспоненциальность форме, их атомарность поменяется? ;) > То есть декомпозиция есть в точности изменение атомарности. Таким образом, > ваша сентенция внутренне противоречива. Нет здесь противоречия. Ваша декомпозиция в данном случае - изменение формы представления, а не изменение атомарности. Суть характеристики не меняется. > для частной задачи мы можем представить характеристику «момент > наступления события» как атомарное значение типа DATE Все временные характеристики реально будут иметь одинаковый тип timestamp. Вы можете задать precision для типа - и только. Согласитесь, это как бы совсем не изменение атомарности. Наличие в разных СУБД различных типов данных, связанных со временем - просто средство упростить жизнь разработчику и пользователю. > Так и завершим спор, если спорить не о чем. ОК. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2005, 10:56 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
guest_20040621Все временные характеристики реально будут иметь одинаковый тип timestamp. Вы можете задать precision для типа - и только. Согласитесь, это как бы совсем не изменение атомарности.Я бы согласился с Вами, если бы только сегодня не наступил на эти грабли. Именно со временем. В таблице, предполагающей хранение только даты (без времени), оказались данные с ненулевым значением часов/минут. В результате система начала сбоить. Откуда там такие данные - пока не понял, но буду бить по рукам того, кто туда эту хрень заносит. Скорей всего себя самого, но это не так уж и важно... Для меня выходом было бы наличие в базе отдельно типа DATE, TIME & TIMESTAMP (DATETIME), но увы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2005, 12:09 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
> Я бы согласился с Вами, если бы только сегодня не наступил на эти грабли. Павел, а я-то здесь при чем? Кто-то криво спроектировал базу данных, кто-то туда чего-то не то написал, а шишки на меня? ;)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2005, 12:18 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
guest_20040621 Где шишки? Какие шишки? Просто в данном случае "дата" никак не должна быть "timestamp", вот и всё. Гранулированность в данном случае - не вопрос представления , как пытаетесь утверждать Вы, но требование логики системы . Вот и всё. Базу кстати я проектировал. В этом месте кривовато получилось, да.... :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2005, 12:52 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
guest_20040621Принципиальная разница между доменом и приведенным примером. Публичные идентификаторы имеют определенного грантора и применимы исключительно к определенным сущностям. ...и таким образом, атомарны относительно определенного генератора, определенных сущностей и определенных систем, в которых эти сущности используются. Даже вне рамок системы номер паспорта _всегда_ будет оставаться номером паспорта. В любой предметной области. ;) Из этого никак не следует, что номер паспорта останется атомарным в любой предметной области. Например, в паспортно-визовом учете иностранцев/мигрантов. Чтобы уменьшить ошибки ввода вам придется анализировать форматы номеров в зависимости от стран. В самом номере есть косвенная информация о месте и времени выдачи, т.е. даже сторонняя (вне МВД) аналитика по разрядам и группам дает информацию о распределении пулов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2005, 12:58 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
> Просто в данном случае "дата" никак не должна быть "timestamp", вот и всё. ;) Ну просто неверно в данном конкретном случае архитектор выбрал precision. И не проверяет значение дополнительно. > Гранулированность в данном случае - не вопрос представления, как пытаетесь > утверждать Вы, но требование логики системы. Вот и всё. ;) Неважно, какими именно соображениями выбрана precision. Это может быть логика системы, недостаток информации, другие ограничения, - факт в том, что информации больше, чем содержиn timestamp, взять неоткуда. А уменьшать это количество информации или использовать более удобное представление - собственно, все возможные действия разработчика. ;)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2005, 13:55 |
|
||
|
Споры о первичном ключе
|
|||
|---|---|---|---|
|
#18+
Frankie Я считаю, что допустимо строить первичный ключ с возможностью хранения какой-то ещё характерной информации. ... Таким образом, как мне кажется, я повышаю целостность таблицы и экономлю место. Нифига ты не повышаешь. Более того, если ты в одно поле запихиваешь три - нарушаеть таким образом 1НФ. Это конечно не так страшно, но все же... Frankie Более общие разногласия сводятся к использованию LIKE. Я не вижу в этом чего-то предосудительного, тогда как мой начальник считает, что это не Если LIKE по ключу - это как-то нелепо выглядит. Frankie процедур. Мне интересно ваше мнение по этой проблеме. Твой друх прав по крайней мере в одном - нельзя в первичный ключ запихивать что-то хоть как-то относящееся к предметной области, логике работы программы и тому подобному. Т.е. можно, конечно, но чревато последствиями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2005, 13:56 |
|
||
|
|

start [/forum/topic.php?fid=32&startmsg=33028204&tid=1545898]: |
0ms |
get settings: |
8ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
32ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
83ms |
get tp. blocked users: |
1ms |
| others: | 225ms |
| total: | 383ms |

| 0 / 0 |
