powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Споры о первичном ключе
25 сообщений из 165, страница 5 из 7
Споры о первичном ключе
    #33028204
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел, т.е. в таблице dogovor поле client_id не зависит от document_id?
...
Рейтинг: 0 / 0
Споры о первичном ключе
    #33028208
Фотография Павел Воронцов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
нумерацию документов имелось в виду.
...
Рейтинг: 0 / 0
Споры о первичном ключе
    #33028266
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Ладно, не знакомо, так незнакомо, проехали.

Нет, не проехали. Какое определение Вы имели в виду? Каких систем и каких объектов?

> Примеры были приведены для опровержения вашего "общего случая"
> независимости атомарности от рамок рассматриваемой системы.

Хех, ну х. з., кто с логикой дружит, а кто нет. Вы утверждали (и утверждаете, насколько я понял), что атомарность атрибутов относительна. Я утверждал (и утверждаю), что есть такие атрибуты, для которых это утверждение в общем случае неверно. Для обоснования своей точки зрения я использовал _приведенные Вами_ примеры, когда атрибуты, которые по-Вашему относительно атомарны, таковыми не являлись. Я никогда и нигде не писал, что атомарность _любых атрибутов_ абсолютна и неизменна. Читать-то Вы, надеюсь, умеете?

Далее я просил (тАвАриСТЧА mir, правда, но это как бы неважно) показать, как будет меняться атомарность атрибутов (список в сообщении был) в зависимости от предметной области. Вместо ответа получил полную ахинею об атомарности времени (это просто прорыв в проектировании какой-то; наверное, навеяно _личным участием_ тАвАриСТЧА mir в разработке АСУ ТП).

Что нелогично и где именно, по-Вашему?

> Поэтому, чтобы не сойти за болтуна, потрудитесь таки обосновать свое общее
> утверждение более весомыми утверждениями, чем "это очевидно".

Не понимаю, какие еще обоснования Вам нужны. Что непонятно в написанном?
...
Рейтинг: 0 / 0
Споры о первичном ключе
    #33028448
Frankie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 gardenman.
Отлично! Мне действительно понравилось. Возможно это прозвучит странно, но другого решения такой задачи я и не видел.

gardenmanкогда я что-то проектирую я менньше всего думаю о нормальных формах. Просто несколько принципов: Каждое значение атрибута должно появляться по возможности только 1 раз, в одной таблице и в одной строке. Количество объектов (индексы, таблицы и прочее) должно быть минимальным. Должна осуществляться жесткая поддержка ссылочной целостности.
Подписываюсь под каждым словом :)

А насчёт идентификации личности по "ФИО, дата и место рождения" - вообще неправильно. Во-первых, что такое место рождения? Роддом что ли? Во-вторых, бывают, знаете ли, полные тёзки, родившиеся в один день. А если у нас люди с разным гражданством и в документе ФИО (если есть О) написаны разным алфавитом? У арабов например вообще имена гигантские, а в корее очень много однофамильцев... Неее, "ФИО, дата и место рождения" это никак уж не гарантирует уникальности.
...
Рейтинг: 0 / 0
Споры о первичном ключе
    #33028462
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 guest_20040621
Да конечно мы несем ахинею, конечно, тактичный вы наш. Известно же, что помимо вас никто в принципе ничего не знает и знать не может. Вы, в общем-то поэтому и не обязаны стрго аргументировать свои взгляды. Это пусть другие пишут детальные посты. А вам можно просто сказать "Тогда это просто ошибочная точка зрения". И все. А если и этого мало, тогда добавить "У-у-у...". Такой аргумент уж точно никто не перешибет.
А если серьезно, оспорьте любой из моих постов. С реальными возражениями. К сожалению, помним, что у вас "нет времени описывать всю последовательность рассуждений. Это долго и нудно". Конечно же, если бы время было, вы бы нас... С левой "стандартами", с правой "метаданными", контрольный в голову - "тезаурус".
...
Рейтинг: 0 / 0
Споры о первичном ключе
    #33028654
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторОтлично! Мне действительно понравилось. Возможно это прозвучит странно, но другого решения такой задачи я и не видел.


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
...
Рейтинг: 0 / 0
Споры о первичном ключе
    #33028661
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
тьфу, дату забыл

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
...
Рейтинг: 0 / 0
Споры о первичном ключе
    #33028761
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> А если серьезно, оспорьте любой из моих постов. С реальными возражениями.

Легко. Например, Ваш пример со временем. Речь идет не об изменении атомарности, а о точности измерения и декомпозиции. Как у времени может меняться атомарность, если по сути это число + единица измерения + точка отсчета, поясните, пожалуйста?
...
Рейтинг: 0 / 0
Споры о первичном ключе
    #33028774
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
FrankieНеее, "ФИО, дата и место рождения" это никак уж не гарантирует уникальности.
C теоретической точки зрения Вы правы - и при учете населения используется, если не ошибаюсь, номер свидетельства о рождении. Но в то же время в практике госучреждений, в практике обработки плохих данных, импорта всяких ублюдочных dbf-ов, если не текстовых файлов - используется именно этот набор атрибутов. Хватает.
...
Рейтинг: 0 / 0
Споры о первичном ключе
    #33028842
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621Вы утверждали (и утверждаете, насколько я понял), что атомарность атрибутов относительна. Я утверждал (и утверждаю), что есть такие атрибуты, для которых это утверждение в общем случае неверно. Для обоснования своей точки зрения я использовал _приведенные Вами_ примеры, когда атрибуты, которые по-Вашему относительно атомарны, таковыми не являлись. Я никогда и нигде не писал, что атомарность _любых атрибутов_ абсолютна и неизменна. Читать-то Вы, надеюсь, умеете?
Короче говоря, по-вашему "атомарность _любых атрибутов_ абсолютна и неизменна" - ложное утверждение. Согласен.
Это означает, что по-вашему, существуют атрибуты, атомарность которых относительна.
Осталось сделать шажок и объяснить, с какой стати атомапрность остальных атрибутов абсолютна. Ну, вот так их господь создал. Вырезал из гранита.
Я потому и пытался вас навести на определение системы, как совкупности объектов (элементов) и их связей.
Любая декомпозиция на элементы относительна. Если вы помните историю, то сам физический атом в начале считался эээ... атомарным :))
Но потом оказалось, что он тоже состоит из других элементов.
Соответственно, любая ваша декомпозиция системы на сущности, связи и атрибуты также относительна цели моделирования.
...
Рейтинг: 0 / 0
Споры о первичном ключе
    #33028866
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Осталось сделать шажок и объяснить, с какой стати атомапрность остальных
> атрибутов абсолютна.

Хех, их абсолютность - штука тоже условная. ;) Попробую объяснить.
[сильно упрощенно] Если атрибут может быть представлен в виде [грантор][сущность] + [идентификатор_грантора], такой атрибут будет атомарным для всех баз данных, исключая базы данных грантора.

> Ну, вот так их господь создал. Вырезал из гранита.

На самом деле это просто идентификаторы, которые некто/нечто раздает монопольно/условно монопольно.
...
Рейтинг: 0 / 0
Споры о первичном ключе
    #33029003
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621
[сильно упрощенно] Если атрибут может быть представлен в виде [грантор][сущность] + [идентификатор_грантора], такой атрибут будет атомарным для всех баз данных, исключая базы данных грантора.
Что есть грантор? Надеюсь, не фонд Сороса ?


На самом деле это просто идентификаторы, которые некто/нечто раздает монопольно/условно монопольно.
Да забудьте вы про идентификаторы на время. Не плодите лишние сущности. В модели "сущность-связь" на верхнем уровне нет никаких идентификаторов. Они появятся позже, когда возникнет необходимость детализации в рамках реляционной модели. А если в рамках сетевой, например, так и не появятся.
...
Рейтинг: 0 / 0
Споры о первичном ключе
    #33029017
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изучайте логику. В частности т. Геделя.
...
Рейтинг: 0 / 0
Споры о первичном ключе
    #33029025
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Что есть грантор? Надеюсь, не фонд Сороса?

[Публичный] генератор идентификаторов.

> Да забудьте вы про идентификаторы на время. Не плодите лишние сущности. В
> модели "сущность-связь" на верхнем уровне нет никаких идентификаторов. Они
> появятся позже, когда возникнет необходимость детализации в рамках
> реляционной модели. А если в рамках сетевой, например, так и не появятся.

Вроде пока мы в рамках реляционной, так что ни о чем забывать не будем.

ОК, попробуем по-другому.

Есть достаточно большое количество реляционных баз данных. Представьте, что мы получили возможность описать эти базы данных в некоторой специально для этого созданной структуре. Окажется, что некоторые сущности часто выступают в роли атрибутов других сущностей, причем одинаковым образом (я упоминал стандарты, метаописание и тезаурус подразумевая именно задачу создания такой структуры). Более того, за пределами баз данных владельца базы данных, где они являются основным предметом описания, они везде будут выступать в одинаковой роли. Для практического применения нам даже не нужна структура баз данных этого владельца: существенную для нас часть (имя владельца базы данных (или группы владельцев, или условного владельца) и имя этой сущности) мы можем получить и не зная внутренней структуры.

Попробую провести такую аналогию: представьте, что атрибут всегда принимает значения из строго определенной таблицы, заполненной некоторым генератором. Для практических задач не нужно знать правил работы генератора, достаточно знания факта, что все возможные значения атрибута находятся в строго определенной таблице.

Какую бы сущность мы не описывали, рассматриваемый атрибут всегда будет принимать значения только из этой таблицы.

Вот такие "однотабличные" атрибуты не будут относительно атомарными. ;) Примеры я приводил.
...
Рейтинг: 0 / 0
Споры о первичном ключе
    #33029056
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621ОК, попробуем по-другому.
Требование атомарности напрямую следует из определения домена как потенциального множества значений простого типа данных, т.е. среди значений домена не могут содержаться множества значений (отношения). При этом сам домен - допустимое множество значений данного типа - определяется относительно моделируемой системы.

Говоря о ваших "табличных" генераторах вы не замечаете (или не хотите замечать), что суть такого приема проста - вы искуственно вводите в систему(ы) домен (причины такого решения мы не рассматриваем).
Этот домен, конечно, будет атомарен по определению. По вашему личному определению (пока не вырвется за рамки системы, подобно номерам паспортов или соцстраха). Вы сознательно вводите внемодельный артефакт. И пытаетесь на этой основе показать, что существуют (где за пределами вашей реализации?) сущности, атрибуты которых "абсолютно" атомарны :))

Теперь вернитесь к началу
Атомарность атрибутов - понятие не абсолютное, а относительное.

Вы пытаетесь опровергнуть это утверждение введением в сущность искусственных (служебных, системных) атрибутов, которые к тому же не выходят за рамки реализации конкретной системы(систем) :))

Предлагаю таки закруглиться.
...
Рейтинг: 0 / 0
Споры о первичном ключе
    #33029101
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> А если серьезно, оспорьте любой из моих постов. С реальными возражениями.

Легко. Например, Ваш пример со временем. Речь идет не об изменении атомарности, а о точности измерения и декомпозиции. Как у времени может меняться атомарность, если по сути это число + единица измерения + точка отсчета, поясните, пожалуйста?

Вот это уже разговор.

1. Ваша мысль о том, что (упрощаю) речь идет не об изменении атомарности, а о декомпозиции, представляется мне странной и нелогичной. Что такое декомпозиция? По определению разложение, разбиение целого на составные части , то есть смена уровня детальности . То есть декомпозиция есть в точности изменение атомарности . Таким образом, ваша сентенция внутренне противоречива.

2. Теперь еще раз: время в реальном мире есть процесс непрерывный. Дискретизация времени — единственный способ иметь с ним дело в модели, но огрубление при этом неизбежно (по определению). Степень дискретизации и само представление такой характеристики как «момент наступления события» может быть разной и определяется целью создания модели (в нашем случае — базы данных). Об этом в точности я и говорил.

То есть для частной задачи мы можем представить характеристику «момент наступления события» как атомарное значение типа DATE (представление) с точностью до дня (степень дискретизации). Пример: атрибут «дата рождения» в системе кадрового учета. Для другой частной задачи мы можем представить характеристику «момент наступления события» как совокупность атрибутов [Год: INT, Месяц: INT, День:INT, Время: TIME] (представление) с точность до миллисекунды (степень дискретизации). Пример: замеры с датчика в промышленной системе.

Вывод: как детальность, так и способ представления информации о предметной области в общем случае не абсолютны, а относительны. Они определяются целью создания системы и ограничениями, налагаемыми на систему.

Разумеется, никто не отрицает, что некоторые характеристики некоторых сущностей от системы к системе практически не меняют ни представление, ни детальность. Вес и рост человека обычно вещественное число, суррогатные первичные ключи всегда атомарны (хотя представление их меняется: то INT, то LONG INT, то GUID). Такие примеры есть. Тем не менее, я бы прокомментировал их наличие вовсе не тем, что общее правило «не работает», т.е. не является «общим». Тут другое. Возьмем «рост». Ничто не гарантирует, что не появится система, требующая «декомпозировать» рост человека на, к примеру, [«длина ног», «длина туловища», «длина шеи», «длина головы»]. То есть это вопрос потребности, а не принципа. Теперь возьмем суррогатные первичные ключи. Они пожалуй всегда будут атомарными. Однако не забудем, что они не «настоящие» характеристики. Это артефакты, искусственно создаваемые по искусственным правилам. Поэтому законы реального мира на них вообще слабо влияют.

Поскольку вы сказали, что «Я никогда и нигде не писал, что атомарность _любых атрибутов_ абсолютна и неизменна», то по сути с высказанной мной точкой зрения согласны. Так и завершим спор, если спорить не о чем.
...
Рейтинг: 0 / 0
Споры о первичном ключе
    #33029350
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Предлагаю таки закруглиться.

ОК. Пара пояснений.

> Требование атомарности напрямую следует из определения домена как
> потенциального множества значений простого типа данных,

Принципиальная разница между доменом и приведенным примером. Публичные идентификаторы имеют определенного грантора и применимы исключительно к определенным сущностям. Иначе чего б я сразу не провел аналогию с доменами?

> вы искуственно вводите в систему(ы) домен

Ничего не ввожу. Я хочу показать Вам, что существуют формальные критерии определения условно абсолютных атрибутов. Кроме того, ничего более.

> пока не вырвется за рамки системы, подобно номерам паспортов или
> соцстраха

Даже вне рамок системы номер паспорта _всегда_ будет оставаться номером паспорта. В любой предметной области. ;)

> Вы пытаетесь опровергнуть это утверждение введением в сущность
> искусственных (служебных, системных) атрибутов, которые к тому же не
> выходят за рамки реализации конкретной системы(систем) :))

Это я настолько плохо излагаю или Вы невнимательно читаете? ;)) Я никуда не ввожу никаких новых артефактов. Просто показать существование абсолютных атрибутов вполне можно их перечислением. Хотелось решить другую задачу: предложить формальные критерии определения таких атрибутов. Безотносительно конкретной реализации. Получилось с переменным успехом. ;)
...
Рейтинг: 0 / 0
Споры о первичном ключе
    #33029395
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mir, Вы полагаете, если я начну представлять вещественные числа в экспоненциальность форме, их атомарность поменяется? ;)

> То есть декомпозиция есть в точности изменение атомарности. Таким образом,
> ваша сентенция внутренне противоречива.

Нет здесь противоречия. Ваша декомпозиция в данном случае - изменение формы представления, а не изменение атомарности. Суть характеристики не меняется.

> для частной задачи мы можем представить характеристику «момент
> наступления события» как атомарное значение типа DATE

Все временные характеристики реально будут иметь одинаковый тип timestamp. Вы можете задать precision для типа - и только. Согласитесь, это как бы совсем не изменение атомарности.

Наличие в разных СУБД различных типов данных, связанных со временем - просто средство упростить жизнь разработчику и пользователю.

> Так и завершим спор, если спорить не о чем.

ОК.
...
Рейтинг: 0 / 0
Споры о первичном ключе
    #33029665
Фотография Павел Воронцов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621Все временные характеристики реально будут иметь одинаковый тип timestamp. Вы можете задать precision для типа - и только. Согласитесь, это как бы совсем не изменение атомарности.Я бы согласился с Вами, если бы только сегодня не наступил на эти грабли. Именно со временем. В таблице, предполагающей хранение только даты (без времени), оказались данные с ненулевым значением часов/минут. В результате система начала сбоить. Откуда там такие данные - пока не понял, но буду бить по рукам того, кто туда эту хрень заносит. Скорей всего себя самого, но это не так уж и важно...

Для меня выходом было бы наличие в базе отдельно типа DATE, TIME & TIMESTAMP (DATETIME), но увы...
...
Рейтинг: 0 / 0
Споры о первичном ключе
    #33029701
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Я бы согласился с Вами, если бы только сегодня не наступил на эти грабли.

Павел, а я-то здесь при чем? Кто-то криво спроектировал базу данных, кто-то туда чего-то не то написал, а шишки на меня? ;))
...
Рейтинг: 0 / 0
Споры о первичном ключе
    #33029803
Фотография Павел Воронцов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621

Где шишки? Какие шишки? Просто в данном случае "дата" никак не должна быть "timestamp", вот и всё. Гранулированность в данном случае - не вопрос представления , как пытаетесь утверждать Вы, но требование логики системы . Вот и всё.

Базу кстати я проектировал. В этом месте кривовато получилось, да.... :-)
...
Рейтинг: 0 / 0
Споры о первичном ключе
    #33029828
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621Принципиальная разница между доменом и приведенным примером. Публичные идентификаторы имеют определенного грантора и применимы исключительно к определенным сущностям.
...и таким образом, атомарны относительно определенного генератора, определенных сущностей и определенных систем, в которых эти сущности используются.

Даже вне рамок системы номер паспорта _всегда_ будет оставаться номером паспорта. В любой предметной области. ;)
Из этого никак не следует, что номер паспорта останется атомарным в любой предметной области.
Например, в паспортно-визовом учете иностранцев/мигрантов. Чтобы уменьшить ошибки ввода вам придется анализировать форматы номеров в зависимости от стран.
В самом номере есть косвенная информация о месте и времени выдачи, т.е. даже сторонняя (вне МВД) аналитика по разрядам и группам дает информацию о распределении пулов.
...
Рейтинг: 0 / 0
Споры о первичном ключе
    #33030053
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Просто в данном случае "дата" никак не должна быть "timestamp", вот и всё.

;) Ну просто неверно в данном конкретном случае архитектор выбрал precision. И не проверяет значение дополнительно.

> Гранулированность в данном случае - не вопрос представления, как пытаетесь
> утверждать Вы, но требование логики системы. Вот и всё.

;) Неважно, какими именно соображениями выбрана precision. Это может быть логика системы, недостаток информации, другие ограничения, - факт в том, что информации больше, чем содержиn timestamp, взять неоткуда. А уменьшать это количество информации или использовать более удобное представление - собственно, все возможные действия разработчика. ;))
...
Рейтинг: 0 / 0
Споры о первичном ключе
    #33030065
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Frankie
Я считаю, что допустимо строить первичный ключ с возможностью хранения какой-то ещё характерной информации. ... Таким образом, как мне кажется, я повышаю целостность таблицы и экономлю место.

Нифига ты не повышаешь. Более того, если ты в одно поле запихиваешь три - нарушаеть таким образом 1НФ. Это конечно не так страшно, но все же...

Frankie
Более общие разногласия сводятся к использованию LIKE. Я не вижу в этом чего-то предосудительного, тогда как мой начальник считает, что это не

Если LIKE по ключу - это как-то нелепо выглядит.

Frankie
процедур. Мне интересно ваше мнение по этой проблеме.

Твой друх прав по крайней мере в одном - нельзя в первичный ключ запихивать что-то хоть как-то относящееся к предметной области, логике работы программы и тому подобному. Т.е. можно, конечно, но чревато последствиями.
...
Рейтинг: 0 / 0
Споры о первичном ключе
    #33030074
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Еще хотел сказат. Если такое добро устроить НЕ в РК - то вполне себе хорошее решение (ну если конечно сознаешь, что это дублирование данных и это не пугает).
...
Рейтинг: 0 / 0
25 сообщений из 165, страница 5 из 7
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Споры о первичном ключе
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]