Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 30 31 32 33 34 [35] 36 37 38 39 .. 83   вперед  Ctrl
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
ЗлОй !

1. ISBN нет даже у книг, выпущенных издательствами. Приводите лучше примеры приложений в хорошо известных Вам областях.
2. Причем здесь ВПК ? Вы проектируете БД, и решаете вопрос с ключами, насколько я понял, а не ВПК.
3. Вы упорно не обращаете внимания на мои слова. В частности по этому, третьему, пункту. К тому же в ОМД для объекта тоже можно объявить идентификатор, определяемый пользователем. Но Вы принципиально не хотите приводить целостные примеры...
2 окт 04, 22:16    [1004321]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Раз по-существу больше никто ничего говорить не хочет, что же мы получили, бегло сравнив дореляционную ОМД с РМД ?

1. Идентификаторы в ОМД принципиально отличаются от первичных ключей (в том числе и суррогатных) в РМД. Идентификаторы эффективнее.

2. Между ссылками в ОМД и внешними ключами в РМД вообще нет ничего общего. Ссылка - альтернативный способ представления связи в ОМД; связь, интегрированная в объект. Многие разработчики ВООБЩЕ НЕ ИСПОЛЬЗУЮТ ссылки, предпочитая ТОЛЬКО ЯВНЫЕ связи. Роль внешних ключей в РМД никому не известна.

3. Уникальные характеристики в ОМД аналогичны АЛЬТЕРНАТИВНЫМ, ОПРЕДЕЛЯЕМЫМ ПОЛЬЗОВАТЕЛЯМИ, ключам в РМД. Уникальные характеристики в ОМД могут использоваться для организации связи между приложениями. Для чего именно используются АЛЬТЕРНАТИВНЫЕ КЛЮЧИ в РМД так никто и не признался.

4. Большинство (мягко говоря) профессиональных разработчиков в "Р"СУБД используют суррогаты в качестве первичных ключей (так как в "Р"СУБД нет возможности использовать более эффективные идентификаторы).

5. Полный провал ключей (почти все используют суррогаты), а, следовательно, и функциональных зависимостей и теории нормализации в РМД, очевиден. Следовательно, очевидна и практическая бесполезность РМД (но не "Р" - см. п. 8). Это подтверждает и отсутствие РСУБД на рынке (РМД настолько плохо формализована, что ее невозможно реализовать).

6. Выражения типа "я пришел в библиотеку (на завод), а там РСУБД такая-то (или такая-то)" стали возможны благодаря исключительно коммерческим усилиям крупных фирм, которые теперь сами не знают что делать с тяжелым наследием большой стратегической ошибки - попытки создать РСУБД.

7. Выросло целое поколение людей, которых недальновидные преподаватели обучили реляционной теории, забыв обучить теории баз данных. И, они, в общем-то, правы, когда говорят: "надо же, как хорошо нас обучили - куда не придешь - везде РСУБД". И вся эта игра для взрослых называется "эпоха РСУБД". РСУБД не было, а эпоха РСУБД была.

8. Во всей этой тридцатилетней коммерческой эпопее было одно здравое зерно - декларативный язык запросов. Но чтобы здравое зерно выросло бы в здравый смысл, нужно было приложить большие усилия в теории баз данных, а не в реляционной теории. Уму непостижимо: за тридцать лет так и не получилось создать интегрированный язык "реляционных баз данных" (как был MUMPS единственным интегрированным языком баз данных с 1969 года, так и остался).

Тем не менее, мне было интересно обсуждать тему "Роль ключей в РМД" на столь представительном форуме. Жаль, что так и не удалось добраться до аспекта манипулирования данными в рамках сравнения СУБД, ведь там у сторонников "Р"СУБД предполагалось большое теоретическое преимущество.
Поэтому все мои предложения остаются в силе.
2 окт 04, 22:46    [1004328]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
>Раз по-существу больше никто ничего говорить не хочет, что же мы получили, бегло сравнив дореляционную ОМД с РМД ?
Кто получил, а кто и не получал.

>1. Идентификаторы в ОМД принципиально отличаются от первичных ключей (в том числе и суррогатных) в РМД. Идентификаторы эффективнее.

Кое-чем отличаются. Одни обязательно генерятся системой, другие нет.
Однако, чтобы пользователь мог идентифицировать объекты, первичные ключи все еще нужны и в ООМД: OID, особенно не видимые, пользователю в этом не помошники. И без PK этот пользователь насоздает много равных объектов вместо одного, но с разными OID.


>Роль внешних ключей в РМД никому не известна..

Все, что не известно Андрею Леонидовичу, естественно, не известно и всем. А если учитывать, что ему, судя по его постам, мало чего известно, то плохи у всех дела.

>3. Уникальные характеристики в ОМД аналогичны АЛЬТЕРНАТИВНЫМ, ОПРЕДЕЛЯЕМЫМ ПОЛЬЗОВАТЕЛЯМИ, ключам в РМД. Уникальные характеристики в ОМД могут использоваться для организации связи между приложениями. Для чего именно используются АЛЬТЕРНАТИВНЫЕ КЛЮЧИ в РМД так никто и не признался.

В то время как общепринятая практика использовать для связи между приложениями системы сообщений, разные технолгии типа OLE и т.д. Андрей Леонидович использует для них средства ограничений целостности моделей данных БД. При этом он считает, что уникальные харакреристики (в литератре просто ключи в ООМД) аналогичны АЛЬТЕРНАТИВНЫМ, ОПРЕДЕЛЯЕМЫМ ПОЛЬЗОВАТЕЛЯМИ, ключам в РМД, но последние ему не известны за чем. По видимому, ему не известны за чем и первые на самом деле.

4. Большинство (мягко говоря) профессиональных разработчиков в "Р"СУБД используют суррогаты в качестве первичных ключей (так как в "Р"СУБД нет возможности использовать более эффективные идентификаторы).

Но меньшиство любителей (грубо говоря) типа Андрея Леонидовича готовы разъяснить им что надо делать в действительности. Жаль, что они пренебрегают теми методами разъяснений, которые только и умеет Андрей Леонидович.

6. Выражения типа "я пришел в библиотеку (на завод), а там РСУБД такая-то (или такая-то)" стали возможны благодаря исключительно коммерческим усилиям крупных фирм, которые теперь сами не знают что делать с тяжелым наследием большой стратегической ошибки - попытки создать РСУБД.

А ведь этим фирмам всего лишь надо было обратиться к Андрею Леонидовичу. Тогда бы не было ситуации - 90% всех используемых БД реляционные. Не было бы этого прорыва в производительности ИС. А сидели все со своим мало кому нужными системами типа его, с непонятной моделью данных. Объектная, но с фиксированными объектами (без ООП) и новигацией, без ключей и непроцедурных языков БД.

>. Полный провал ключей (почти все используют суррогаты), а, следовательно, и функциональных зависимостей и теории нормализации в РМД, очевиден. Следовательно, очевидна и практическая бесполезность РМД (но не "Р" - см. п. 8). Это подтверждает и отсутствие РСУБД на рынке (РМД настолько плохо формализована, что ее невозможно реализовать).

Андрей Леонидович забыл свою мысль - ключи не нужны: ведь кортеж итак уникален. Что скрывается за термином провал, тем более полный полный и как он связан с сурогатами не известно, судя по всему, и самому Андрею Леонидовичу, но это не имеет значения. Тем более, что суррогаты никак не могут оказать влияния на функциональные зависимости и даже нормализацию, и от того провал оных тем более нужен Андрею Леонидовичу как очевидный. Он любит провалы сами по себе в силу природы вещей.
Отсутствие на рынке РСУБД, однако, не подтверждает и того, что система Андрея Леонидовича является даже СУБД (возможно это просто некий язык по работе с файлами и кое каким операциям с фиксированными объектами), а тем более попадает в список СУБД заявленных в теме. Т.е. она ни РСУБД, ОРСУБД, ни ООСУБД.

>7. Выросло целое поколение людей, которых недальновидные преподаватели обучили реляционной теории, забыв обучить теории баз данных. И, они, в общем-то, правы, когда говорят: "надо же, как хорошо нас обучили - куда не придешь - везде РСУБД". И вся эта игра для взрослых называется "эпоха РСУБД". РСУБД не было, а эпоха РСУБД была.

Скромность Андрея Леонидовича призводит сильное впечатление. Наш великий учитель. Видать он многим из этого поколения пытался доказывть свои мысли, но увы эпоха РСУБД была. И еще видно не совсем закончилась, а эпоха его модели плоские файлы уже прошла 30 лет назад и его мысли все еще не востребованы этими поколениями, а, возможно, и их потомками.

>8. Во всей этой тридцатилетней коммерческой эпопее было одно здравое зерно - декларативный язык запросов. Но чтобы здравое зерно выросло бы в здравый смысл, нужно было приложить большие усилия в теории баз данных, а не в реляционной теории. Уму непостижимо: за тридцать лет так и не получилось создать интегрированный язык "реляционных баз данных" (как был MUMPS единственным интегрированным языком баз данных с 1969 года, так и остался).

К несчатью, уму Андрея Леонидовича многое не постижимо. С другой стороны ему к этому не превыкать. Но у него есть язык 1969 MUMPS. Правда, может это несчастье для тех, кто пользуется его системой. Но эим можно пренебречь - его система пока не относится к распространенным, и потому число инсталяций этих устаревших систем не так велико.

>Тем не менее, мне было интересно обсуждать тему "Роль ключей в РМД" на столь представительном форуме.

У Андрея Леонидовича весьма специфическая манера обсуждения. Делать фантастические или туманные заявления, обещать их доказать, на вопросы опровергающие не отвечать, а потом просто делать вид, что он их доказал.
Ему это интересно, не смотря на то, что это не принято в технической среде, и даже не совсем прилично, и тем более бесполезная трата времени.

Жаль, что так и не удалось добраться до аспекта манипулирования данными в рамках сравнения СУБД, ведь там у сторонников "Р"СУБД предполагалось большое теоретическое преимущество.

Читай: Жаль, что так и не удалось наделать массу идиотских заявлений про аспекты манипулирования данными. Наобещать с три короба доказательств. Налить воды, а потом сделать вид, что доказал их полный провал.

Могу себе предствить ту организацию где работает Андрей Леонидович, и те системы что он создает. Впрочем, надеюсь что создают другие, а он применяет подобные методы и высказывает такого рода мысли только здесь.
3 окт 04, 01:14    [1004381]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Один
Guest
vadiminfo

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

А что там представлять ?
Вот Андрей Леонидович.
Вот где он работает.
Мне понравилась Сравнительная характеристика СУБД (таблица внизу страницы)

ИМХО сайт говорит сам за себя.
3 окт 04, 01:47    [1004394]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ChA
Member

Откуда: Москва
Сообщений: 11373
Честно говоря, иногда заглядываю сюда в надежде на что-то большее, чем препирательства ЧАЛ и vadiminfo. Чего не могу понять, так это переход на личности. В этом смысле, ЧАЛ более корректен, более того, я его пониманию, ему нужны новые адепты, распространение их продукта, вот он и тянет, а вдруг ? Зачем остальные-то пытаются ему способствовать в этом, я, лично, давно перестал понимать. Блеснуть своим интелектом ? У Дон Кихота проблемы с головой были, а вам-то зачем с ветряной мельницей сражаться ? Можно понять тех, кто заглянул сюда впервые, хочется шашкой помахать, счас, типа, уделаю... Ахха... vadiminfo, ну попробуйте Вы пропустить мимо ушей замечания коллеги ЧАЛ, умных слов здесь уже много было говорено, а переходить на личности, право слово, не стоит. Если тема интересует, так сами ее двигайте, инциатива давно уже у "противника". Поднимайте те вопросы, которые Вам интересны !

С уважением ко всем участникам дискуссии.

P.S. Предлагаю коллеге ЧАЛ открыть свой топик с названием типа "Информ Икс" или "Крах РМД". Sorry за сокращение ФИО...
3 окт 04, 05:07    [1004424]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Андрей Леонидович

>Раз по-существу больше никто ничего говорить не хочет...

Надо понимать что Андрей Леонидович на заданные вопросы отвечать уже не будет. Несмотря на самопровозглашенный лозунг: "Я то, как раз, на все вопросы отвечаю".

Итак в результате проведенной дискуссии, даже исключив анализ существа вопроса, имеем документально подтвержденные: плагиат, передергивание высказываний оппонентов, теперь еще и откровенная неправда.
3 окт 04, 11:02    [1004464]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
2 ChA

Возможно, я не корректен был по отношению к Андрею Леонидовичу. Но он ведь тоже по сути оговорил нас. Т.е. обещал доказать фантастическое утверждение. Доказывать не стал, на опровергающие вопросы отвечать прямо не стал, а потом сделал вид, что доказал. Нам т.е. нам доказал - мы получили. Т.е. получается, что мы по этому вопросу думаем теперь как он. А ведь за такие мысли могут с работы выгнать - не соответствие занимаемой должности, диплома лишить. Ведь это элементарные вещи в вопросах БД. В них путаться имеет право начинающий студент и то только до первого экзамена. А о он нам и в том числе мне (а я против, чтобы мне такое приписывали) их приписал - ведь мы это получили, в результате дискуссиии получили, у нас теперь нет белых пятен про ключи. А кто будет читать что там было? Никто. Мне это и не нравится, что я якобы тоже пришел к такому итогу. Это оговор, наглый и беспардонный. А что же еще? Кому это понравится?
Писал бы он , что это он получил - другое дело. Что он не знает, что такое внешние ключи (нашел чем хвастаться) и т.д.

Кроме того, у него есть и профессиналы (мягко говоря) и недальновидные преподаватели и целое поколение ими обученное, т.е. тоже все недальновидные или того хуже. Не знаю на сколько это корректно.
Мне было интересно, что он ответит на вопросы про его утверждения, а но взял и "получил" вместе с нами, не отвечая на вопросы, потому что мне не нужны ответы. Он так решил. А я ведь изначально наделся, что он будет соблюдать элементарные правила ведения дискуссии.

Впрочем, если мои слова были не приятны в плане этики, приношу извинения.
3 окт 04, 15:58    [1004579]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Андрей Леонидович

1. ISBN нет даже у книг, выпущенных издательствами. Приводите лучше примеры приложений в хорошо известных Вам областях.
2. Причем здесь ВПК ? Вы проектируете БД, и решаете вопрос с ключами, насколько я понял, а не ВПК.
3. Вы упорно не обращаете внимания на мои слова. В частности по этому, третьему, пункту. К тому же в ОМД для объекта тоже можно объявить идентификатор, определяемый пользователем. Но Вы принципиально не хотите приводить целостные примеры...


1. У книг изданных нормальным издательством ISBN есть. Если Вася Пупкин напечатал на лазерном принтере некую брошюру и переплел ее, то книгой она от этого не стала.

2. ВПК - конкретный пример предметной области.

Идентификатор объекта - понятие мне хорошо знакомое. Во-первых из языка программирования java, во-вторых по возне с биллинговой системой одного американского сотового оператора. Сия система была написана на smalltalk, и базировалась на СУБД написанной на нем же.

Что общего у идентификатора объекта и суррогатного ключа:
- оба уникальны
- оба используются системой для идентификации неких структур данных, моделирующих сущности предметной области
- их значения имеют смысл только для СУБД, с точки зрения человека знающего предметную область они смысла не имеют
- оба присваиваются системой, без непосредственного участия в этом процессе человека

Соответственно и недостатки у них одни и те же. Ибо у этих недостатков "ноги растут" из общих свойств суррогатного ключа и идентификатора объекта. Пример был приведен, с ИНН. Никакая система, будь она хоть семи пядей во лбу, не сможет однозначно и безошибочно ответить на данный вопрос:

Злой

Жан-Мишель Сери родившийся 12 ноября 1970 г. в Лионе и имеющий идентификационный номер налогоплательщика Х это одно и то же лицо что и "Жан-Мишель Сери родившийся 12 ноября 1970 г." и обращающийся за новым номером, или полный тезка родившийся в тот же день?


С номенклатурой ВПК та же фигня, человек знакомый с конструкцией комплексов 9К117 и 9К119 решает что они - разные. Никакая СУБД это решение принять не может. Ибо СУБД не способна мыслить и ничего не понимает в ракетных комплексах.

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

Вы утверждаете что между суррогатными ключами и идентификаторами объектов есть существенное отличие. Просьба объяснить простым доступных русским (или английским - на ваше усмотрение) языком в чем же это отличие заключается. А то все ходим, вокруг да около, эффективность какую-то придумали. В чем разница-то конкретно, без расплывчатых фраз. ИМХО в нашей области знаний, любой кто не может "на пальцах" объяснить идею, обычно сам её до конца не понимает. Мы же не тензоры перемножаем, и не общей топологией занимаемся. Наша область знаний вполне конкретная.

Ссылки и внешние ключи, с точки зрения концепции, решают одну и ту же задачу. Просто они ее различными способами решают. Кстати "ссылочной целостностью" эту задачу называли еще в начале 70х, до изобретения реляционных СУБД. Модели меняются (Иерархическая, Сетевая, Реляционная, теперь вот Объектная). А задачи ими решаемые остаются :)

Грамотные разработчики реляционных СУБД используют суррогатные ключи где следует, и не используют где не следует. Разработчики лепящие суррогаты где попало - халтурщики.

"провал ключей" - громкая, трескучая фраза, вдобавок ничем не аргументированная. Насчет "выросло реляционное поколение" вы напрасно. Я изучал и сетевые и иерархичесие СУБД. Работал с объектной СУБД на smalltalk. И даже сейчас с IMS работаю, когда возникает необходимость. Так что не надо нам петь песни какое г. эта реляционная модель. Любой кто работал с нереляционной, знает какое г. эти иерархические-сетевые-объектные СУБД.
4 окт 04, 08:36    [1004981]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Morisson
Member

Откуда:
Сообщений: 13
Зл0й

1. У книг изданных нормальным издательством ISBN есть. Если Вася Пупкин напечатал на лазерном принтере некую брошюру и переплел ее, то книгой она от этого не стала.

Можно поспорить с вашими примерами идентификации по несуррогатному ключу.
ISBN'у всего от силы 30 лет. А что же выпускалось ранее (ведь несколько сот лет, как книгопечатание появилось) - "некниги"? Хорошо, выделим их в отдельную сущность "некниги". Как при этом идентифицировать каждую некнигу? По суррогатному ключу все таки? ;)

С применением ИНН для идентификации человека тоже есть ограничения. ИНН можно идентифицировать только ВЗРОСЛОГО человека с РОССИЙСКИМ гражданством, прошедшего регистрацию в НАЛОГОВОЙ службе. Остальное человечество остается за бортом этой сущности, т.к. просто не сможет быть идентифицировано.
С ВПК - тоже самое: сущность ограничивается только российской военной техникой и ее российской классификацией (ведь есть же еще NATO'вская классификация нашей техники).
Похоже, что выбор несуррогатного(т.е. имеющего самостоятельное значение) идентификатора для идентификации сущности накладывает на экземпляры сущности ограничение, присущее самому несуррогатному идентификатору в реальной жизни. Несуррогатный идентификатор можно также обозвать значащим идентификатором(в том смысле, что на момент создания экземпляра идентификатор этого э-ра уже существовал в реальной жизни и имел значение).
Из этого следует две причины, почему не следует пользоваться значащими идентификаторами при проектировании структуры БД:
1. Сущность при проектировании обычно выбирается так, что множество экземпляров сущности больше, чем множество экземпляров этой сущности, могущее быть идентифицировано каким-либо значащим идентификатором.
Пример: сущность Человек, идентификатор - ИНН.
2. Вторая причина: время жизни значащего идентификатора может быть короче, чем время жизни сущности. Тогда значение значащего идентификатора пропадает.
Пример: ИНН отменят, а человек останется.
Применение смысловых ключей имеет под собой почву, но только в тех случаях, когда идентификатор экземпляра сущности глобален в мировом масштабе. Например элементы в таблице Менделеева, алфавиты, латинские названия растений и животных. Но, к сожалению, эти примеры сущностей считаны и в, основном, суть справочники.

Как видно из предыдущих абзацев, я не разделял понятия идентификатора и суррогатного ключа. Суррогатный ключ можно действительно назвать идентификатором, т.к. он используется для идентификации кортежа в РМД, как идентификатор используется для идентификации экземпляра в ОМД.
Но, и тут я согласен с Андреем Леонидовичем, разница действительно присутствует: идентификатор не есть один из атрибутов экземпляра. Объект(класс) в ОМД может вообще быть создан без атрибутов, но идентификатор у экземпляров этого объекта будет.
В РМД суррогатный ключ есть часть кортежа, в качестве одного из его полей.
Т.е. в ОМД идентификатор определяет экземпляр сущности- набор конкретных значений атрибутов(идентификатор отдельно, сущность отдельно), а в РМД суррогатный ключ "примешивается" к атрибутам сущности. Я так понял, что вот это "примешивание", в частности, и объявляется Андреем Леонидовичем как "плохая формализация РМД". Действительно, что не могли за столько лет развития РМД продумать четкий и бесспорный механизм идентификации кортежей в таблице чем порождать постоянные думы разработчиков о суррогатном или смысловом ключе для данной конкретной таблицы?
6 окт 04, 16:19    [1013499]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
NDN
Guest
тест

Morisson
Зл0й

1. У книг изданных нормальным издательством ISBN есть. Если Вася Пупкин напечатал на лазерном принтере некую брошюру и переплел ее, то книгой она от этого не стала.

Можно поспорить с вашими примерами идентификации по несуррогатному ключу.
ISBN'у всего от силы 30 лет. А что же выпускалось ранее (ведь несколько сот лет, как книгопечатание появилось) - "некниги"? Хорошо, выделим их в отдельную сущность "некниги". Как при этом идентифицировать каждую некнигу? По суррогатному ключу все таки? ;)

С применением ИНН для идентификации человека тоже есть ограничения. ИНН можно идентифицировать только ВЗРОСЛОГО человека с РОССИЙСКИМ гражданством, прошедшего регистрацию в НАЛОГОВОЙ службе. Остальное человечество остается за бортом этой сущности, т.к. просто не сможет быть идентифицировано.
С ВПК - тоже самое: сущность ограничивается только российской военной техникой и ее российской классификацией (ведь есть же еще NATO'вская классификация нашей техники).
Похоже, что выбор несуррогатного(т.е. имеющего самостоятельное значение) идентификатора для идентификации сущности накладывает на экземпляры сущности ограничение, присущее самому несуррогатному идентификатору в реальной жизни. Несуррогатный идентификатор можно также обозвать значащим идентификатором(в том смысле, что на момент создания экземпляра идентификатор этого э-ра уже существовал в реальной жизни и имел значение).
Из этого следует две причины, почему не следует пользоваться значащими идентификаторами при проектировании структуры БД:
1. Сущность при проектировании обычно выбирается так, что множество экземпляров сущности больше, чем множество экземпляров этой сущности, могущее быть идентифицировано каким-либо значащим идентификатором.
Пример: сущность Человек, идентификатор - ИНН.
2. Вторая причина: время жизни значащего идентификатора может быть короче, чем время жизни сущности. Тогда значение значащего идентификатора пропадает.
Пример: ИНН отменят, а человек останется.
Применение смысловых ключей имеет под собой почву, но только в тех случаях, когда идентификатор экземпляра сущности глобален в мировом масштабе. Например элементы в таблице Менделеева, алфавиты, латинские названия растений и животных. Но, к сожалению, эти примеры сущностей считаны и в, основном, суть справочники.

Как видно из предыдущих абзацев, я не разделял понятия идентификатора и суррогатного ключа. Суррогатный ключ можно действительно назвать идентификатором, т.к. он используется для идентификации кортежа в РМД, как идентификатор используется для идентификации экземпляра в ОМД.
Но, и тут я согласен с Андреем Леонидовичем, разница действительно присутствует: идентификатор не есть один из атрибутов экземпляра. Объект(класс) в ОМД может вообще быть создан без атрибутов, но идентификатор у экземпляров этого объекта будет.
В РМД суррогатный ключ есть часть кортежа, в качестве одного из его полей.
Т.е. в ОМД идентификатор определяет экземпляр сущности- набор конкретных значений атрибутов(идентификатор отдельно, сущность отдельно), а в РМД суррогатный ключ "примешивается" к атрибутам сущности. Я так понял, что вот это "примешивание", в частности, и объявляется Андреем Леонидовичем как "плохая формализация РМД". Действительно, что не могли за столько лет развития РМД продумать четкий и бесспорный механизм идентификации кортежей в таблице чем порождать постоянные думы разработчиков о суррогатном или смысловом ключе для данной конкретной таблицы?
6 окт 04, 19:13    [1014199]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
morrison

Можно поспорить с вашими примерами идентификации по несуррогатному ключу.
ISBN'у всего от силы 30 лет. А что же выпускалось ранее (ведь несколько сот лет, как книгопечатание появилось) - "некниги"? Хорошо, выделим их в отдельную сущность "некниги". Как при этом идентифицировать каждую некнигу? По суррогатному ключу все таки? ;)

Во-первых не обязательно по суррогатному ключу. Во-вторых я не говорил что суррогатные ключи не нужны вообще. В случае с ISBN все новые книги его имеют. С точки зрения моделирования данных разумно будет выделить сущность "книги" с натуральным ключем, и одну или несколько различных сущностей "не-книги" в которых можгут быть свои ключи, натуральные или суррогатные. Если мы строим БД не букинистического магазина, то ISBN однозначно рулит как первичный ключ для сущности "книги".

morrison

С применением ИНН для идентификации человека тоже есть ограничения. ИНН можно идентифицировать только ВЗРОСЛОГО человека с РОССИЙСКИМ гражданством, прошедшего регистрацию в НАЛОГОВОЙ службе. Остальное человечество остается за бортом этой сущности, т.к. просто не сможет быть идентифицировано.

Если мы строим БД работодателя, то наш работник по определению должен иметь ИНН ибо должен платить налоги. Если мы строим БД налоговой инспекции, то "остальное человечество" остается за бортом не зря, ибо находится за пределами интересов налоговой инспекции.


Если же мы пытаемся идентифицировать просто гражданина, вне зависимости от его отношений с налоговой инспекцией, в развитых странах для этого есть номер социального страхования. Если же чел. такого номера не имеет - гнать пинками, чтобы получал.

morrison

С ВПК - тоже самое: сущность ограничивается только российской военной техникой и ее российской классификацией (ведь есть же еще NATO'вская классификация нашей техники).

Классификацию нашей техники по NATO можно сделать как отдельную mapping table. С "натовским" наименованием в качестве первичного ключа. Проблемы для ключей я тут не вижу. Если мы строим БД для российского МО, то вопрос об иностранных наименованиях и иностранных вооружениях на повестке дня не стоит. В тех редких случаях, когда иностранное изделие стоит на воружении (напремер чешсткий УТС L-39 "Альбатрос"), ему присваиваются соответствующие индексы и наименования.

Так что в ряде предметных областей, где задача "упорядочивания" сущности решена, нам суррогатный ключ нафиг не нужен. Я работаю в американском банке, у нас в качестве первичного ключа используется номер карточки социального страхования (Social Security Number). C 70х годов прошлого века используется. Без каких бы то ни было проблем. Главное чтобы в него не засовывали TIN (Taxpayer Identification Nuber) имеющий тот же формат. Но это уже вопрос не технический а организационный - обучение персонала. Когда мы расширили базу на канадцев и мексиканцев, то мы просто добавили еще один атрибут - код страны по ISO и поменяли тип данных, чтобы мексиканские SSN помещались (они длиннее американских). Вот и все. Никаких суррогатных ключей на фиг не надо. Завели бы суррогатный ключ - потом разбирались бы:

г-н Хорхе Хесус Гутиеррес родившийся в г. Сюидид-Хуарез 03.02.1974 г с суррогатным ключем 123

г-н Хорхе Гутиеррес родившийся в г. Сюидид-Хуарез 03.02.1974 г с суррогатным ключем 345

Это -один и тот же персонаж или нет? Зачем мне нагружать сотрудника банка этой задачей? Пусть Social Security Administration этой задачей занимается, ей за это деньги платят. А я у клиента возьму заведомо уникальный SSN, занесу его в систему, и забуду эту "проблему" как страшный сон.


morrison

Пример: ИНН отменят, а человек останется.

Не отменят. Не для того его вводили, чтобы отменять.

morrison

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

Совершенно не обязательно. Если есть некая инстанция которая обеспечивает уникальность натурального ключа, например американская Social Security Administration, Российское Министерство Обороны, то для данной предметной области ключ - "глобален". Если же вдруг оказывается что это не так, то это надо исправить. Ибо нарушение "голобальности" есть нарушение бизнес-логики. Которое допускаться не должно. Система с суррогатными ключами его допускает легко, см. пример с "Хорхе Хесус Гутиеррес".

morrison

Как видно из предыдущих абзацев, я не разделял понятия идентификатора и суррогатного ключа. Суррогатный ключ можно действительно назвать идентификатором, т.к. он используется для идентификации кортежа в РМД, как идентификатор используется для идентификации экземпляра в ОМД.
Но, и тут я согласен с Андреем Леонидовичем, разница действительно присутствует: идентификатор не есть один из атрибутов экземпляра. Объект(класс) в ОМД может вообще быть создан без атрибутов, но идентификатор у экземпляров этого объекта будет.

Объект (класс) без атрибутов это круто. Но абсолютно бесполезно. У объекта должен быть хотябы один атрибут или метод. Иначе зачем нам такой объект? В принципе такой можно реализовать и в реляционной БД. Этакий вырожденный случай - таблица с одной колонкой из суррогатного ключа. И вообще, что значит "идентификатор - не атрибут"? Отношение 1:1 между объектом и идентификатором имеется? Имеется. Чем не атрибут?

morrison

В РМД суррогатный ключ есть часть кортежа, в качестве одного из его полей.
Т.е. в ОМД идентификатор определяет экземпляр сущности- набор конкретных значений атрибутов(идентификатор отдельно, сущность отдельно), а в РМД суррогатный ключ "примешивается" к атрибутам сущности.

Открою вам страшную тайну. В одной из реализаций РМД (СУБД Oracle) имеется тот самый "идентификатор". Называется UROWID. Типа универсальный "номер записи" содержащий в себе номер таблицы. Практическая полезность такого идентификатора близка к нулю. Использкется он только для создания индесов "вручную" в тех редких случаях когда родные индексы почему-то "не канают".

Тут вопрос в доступе к данным. С точки зрения предметной области практическая ценность идентификатора/суррогата нулевая. Ибо с точки зрения предметной области он не содержит никакой информации.

morrison

Я так понял, что вот это "примешивание", в частности, и объявляется Андреем Леонидовичем как "плохая формализация РМД". Действительно, что не могли за столько лет развития РМД продумать четкий и бесспорный механизм идентификации кортежей в таблице чем порождать постоянные думы разработчиков о суррогатном или смысловом ключе для данной конкретной таблицы?

Разруха - в головах (с). Тут дело не в РМД вообще, а в неумении разработчиков анализировать предметную область. Если в предметной области есть натуральный ключ, его надо использовать. Не использование его (использование суррогатов/идентификаторов объектов) приводит к проблеме "Хорхе Гутиеррес" излодженной выше. И объектная БД здесь ничем не лучше реляционной, иерархической, сетевой и любой другой. Суррогат - он и в Африке суррогат. Не важно как он называется. Важно что бороться с "дубликатами" приходится долго, и зачастую безуспешно. Вне зависимости от типа СУБД. Ибо проблема не в СУБД а в постановке задачи. То есть еще задолго до выбора СУБД.
6 окт 04, 20:09    [1014281]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ЗоринАндрей
Member

Откуда: Санкт-Петербург
Сообщений: 3004
автор
Разруха - в головах (с). Тут дело не в РМД вообще, а в неумении разработчиков анализировать предметную область. Если в предметной области есть натуральный ключ, его надо использовать. Не использование его (использование суррогатов/идентификаторов объектов) приводит к проблеме "Хорхе Гутиеррес" излодженной выше. И объектная БД здесь ничем не лучше реляционной, иерархической, сетевой и любой другой. Суррогат - он и в Африке суррогат. Не важно как он называется. Важно что бороться с "дубликатами" приходится долго, и зачастую безуспешно. Вне зависимости от типа СУБД. Ибо проблема не в СУБД а в постановке задачи. То есть еще задолго до выбора СУБД.


Во-первых, наличие суррогата не мешает вводить ограничения типа "SSN непустой уникальный". И ограничение при этом относится только к одной таблице, поскольку этот ваш SSN не расползается по всем таблицам в роли foreign key. Так что проблема дубликатов и суррогаты вещи почти не связанные. Уверяю Вас - суррогатами пользуются не только идиоты.

Во-вторых, компактный суррогат гораздо эффективнее невъе****нных строковых ССНов, или тем паче составных естественных ключей.

В-третьих, наличие ОДНОВРЕМЕННО суррогата в роли первичного ключа и естественных альтернативных ключей снимает головную боль при ошибках ввода этих самых "естественных ключей". Т.е. в Вашем "грамотном" варианте исправление неверно введенного SSN приведет к массе каскадных обновлений в других таблицах. Ну и нахренА это надо?!

В-четвертых, все эти номера паспортов, ССНы, ИННы - по сути тоже чьи-то "суррогаты" только в рамках более крупных систем нежели некая БД.
Что оператор будет делать когда выяснится что уже есть запись с данным ССН?
Полезет в базу смотреть атрибуты Хорхе Гутьереса в поисках НАСТОЯЩИХ атрибутов по которым можно ПОПЫТАТЬСЯ идентифицировать человека.
ССН - это не человек и не атрибут, это суррогат в масштабах страны. :-))

Вы, молодой человек, Тенцера не читали что ли?
Тенцер
"Hичто не вечно под Луной. Самый, казалось бы, надежный атрибут вдруг отменяется и перестаёт быть уникальным. Американцы ругаются на неуникальность номера социального страхования, Microsoft - на китайские серые сетевые платы с дублирующимися MAC-адресами, которые могут привести к дублированию GUID, врачи делают операции по смене пола, а биологи клонируют животных. В этих условиях (и учитывая закон неубывания энтропии) закладывать в систему тезис о неизменности ЕК - закладывать под себя мину."

(Анатолий Тенцер, "Естественные ключи против искуственных ключей", статья 6-20 июля 1999 года)


тынц
6 окт 04, 20:48    [1014321]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Один
Guest
Зл0й

Разруха - в головах (с). Тут дело не в РМД вообще, а в неумении разработчиков анализировать предметную область. Если в предметной области есть натуральный ключ, его надо использовать. Не использование его (использование суррогатов/идентификаторов объектов) приводит к проблеме "Хорхе Гутиеррес" излодженной выше. И объектная БД здесь ничем не лучше реляционной, иерархической, сетевой и любой другой. Суррогат - он и в Африке суррогат. Не важно как он называется. Важно что бороться с "дубликатами" приходится долго, и зачастую безуспешно. Вне зависимости от типа СУБД. Ибо проблема не в СУБД а в постановке задачи. То есть еще задолго до выбора СУБД.

Пока нет Андрея Леонидовича, к-й нам расскажет о сущности сущностей, мы в трехсотый раз поговорим о суррогатные vs естественные ключи (Alien vs Predator).
:)
На самом деле все давно уже для себя определили что им лучше.
Я (лично я) согласен со Злым (наверное можно его ник так склонять, если нет - я извиняюсь), что там, где есть заведомо уникальный ключ, его надо использовать. И здесь вопрос стремительно выходит из области программирования и переходит в сферы высшей политики/экономики/философии. Вспоминаются фразы о стабильности экономики, политической системы, законодательства. Т.е. дискуссия переходит в "воду".

А суть очень простая.
То, что казалось уникальным ключем на этапе проектирования в нестабильной ситуации может оказаться неуникальным ключем [в этом месте приветствуются многочисленные случаи из практики]. Т.е. на дискуссию
Зл0й
morrison
Пример: ИНН отменят, а человек останется.

Не отменят. Не для того его вводили, чтобы отменять.
всегда можно возразить "а вдруг таки отменят" [в этом месте опять приветствуются многочисленные случаи из практики].

Короче говоря.
Я много раз видил, ситуацию, когда в ситеме используется суррогатный ключ. А на "уникальный" атрибут вешается уникальний индекс. Прямо рядом с Pk по суророгату.
Жизнь такая :(
6 окт 04, 20:56    [1014328]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Один
Guest
ЗоринАндрей - ну так не честно :)
Мы об одном и том же.

Эх, 35 страниц флуда о том, может ли атрибут сущности считаться сущностью и не есть ли это ВЕЛИКОЕ ЗЛО и тут на тебе, вывернули на суррогаты или естественные ключи :)

Причем я глубоко убежден, что более-менее грамотные разработчики БД знают все эти нехитрые аргументы сторонников первых и вторых. И тем не менее эти дискуссии возраждаются как феникс из пепла. Почему ? Вот в чем вопрос (С)
6 окт 04, 21:08    [1014343]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Если есть натуральный ключ, то иногда суррогат вешают для удобства. Чтобы писать "a.id = b.id" вместо "a.col1= b.col1 and a.col2 = b.col2 and ...". Да и сравнивать числа быстрее чем длинные строки. Так что суррогат введенный для удобства, при наличии ограничения "уникальный, не пустой" на натуральном ключе - вполне канает. Особенно если натуральный ключ состоит из 5-7 атрибутов. Хотя производительность это зависит от реализации. В Teradata по primary index считается хэш-функция. Существенной разницы между ключем из одного атрибута и пяти вы там не увидите.

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

Я противник применения суррогатов там, где можно обойтись натуральным ключем. Например девятизначный американский номер социального страхования вполне канает в качестве ключа. Можно называть его "суррогатом в масштабах страны" но ИМХО это будет неправильно. Ибо суррогат по определению присваивает машина. Тупо и злобно, безо вского мыслительного процесса. А SSN присваивает человек, сотрудник американской SSA. Который "шарит" в предметной области и обеспечивает 1 человек : 1 SSN.

Если заводить собственный суррогат - значит возлагать работу уже сделанную сотрудником SSA на пользователя системы. Зачем? ИМХО незачем.

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


Андрей Леонидович насы пытается убедить в ненужности натуральных ключей, и в необходимости везде использовать суррогаты. Я в корне не согласен с таким подходом. Не люблю делать чужую работу. Не считаю что сотрудники моей организации должны тратить свое время делая чужую работу. Сотрудник банка не должен решать проблему присвоения уникального id клиенту - физ.лицу. Для этого есть Social Security Number. "Изобретать велосипед" не надо. Вот мои возражения, Андрею Леонидовичу. По Тенцеру же в этом случае мы имеем дополнительный атрибут (суррогатный ключ) в отношении 1:1 к SSN. Зачем - непонятно. Кроме того мы имеем как минимум 2 функциональные зависимости:

SSN -> Имя, Фамилия, ...
суррогатный ключ -> Имя, Фамилия, ...

Налицо очевидная избыточность. И дополнительная, пусть небольшая, нагрузка на СУБД - проверять 2 ключа вместо одного.
6 окт 04, 22:00    [1014380]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ЗоринАндрей
Member

Откуда: Санкт-Петербург
Сообщений: 3004
Начальник: введи в базу Васю Пупкина
Секретарша: не могу, программа не дает ввести ССН который у него в анкете, говорит он занят Хосе Гутьересом.
Начальник: кто программу писал?
Секретарша: Зл0й программист.
Начальник: значит так. на ССН мне наср.ть. придумай от балды - с ССН потом разберемся. Вася Пупкин должен быть в базе сегодня. А Зл0го программиста - уволить нахрен.

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

З.Ы. с Тенцером и Леонидычем разбирайся сам, я от этих споров тупоконечников с остроконечниками за пять лет устал уже.

З.З.Ы. иногда складывается впечатление что человек наступивший разок на грабли потом шарахается от всего что отдаленно напоминает садовый инвентарь.

З.З.З.Ы государственная машина выдающая ССН глючит ничуть не меньше.

З.З.З.З.Ы. если "зачем непонятно" значит невнимательно читал.
7 окт 04, 02:52    [1014495]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
>Начальник: введи в базу Васю Пупкина
Секретарша: не могу, программа не дает ввести ССН который у него в анкете, говорит он занят Хосе Гутьересом.


Есть еще одина ситуация, абсолютно жизненная, когда Вася Пупкин свой ССН с собой не носит и конечно же не помнит, но обещает завтра принести (перезвонить и сказать). А в БД нужно внести сегодня. И дальше по тексту.
7 окт 04, 03:34    [1014507]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
x
Guest
Опять суррогатные против естественных - неинтересно, ни одного нового аргумента.

Лучше уж пусть Андрей Леонидович объяснит чем идентификатор объекта ПРИНЦИПИАЛЬНО отличается от ключа. Вдруг действительно я чего-то непонимаю.
7 окт 04, 10:52    [1015128]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Пример с секретаршей не канает. Если грязные данные допускаются - пусть в Excel заносит, БД там нужна "как собаке пятая нога". Я работаю в банке, где есть правила, которым надо следовать. Если кто-то им не следует, получает по шее от:

1. Начальства
2. Внутреннего аудита
3. Государственных проверяющих (OCC, FDIC, ...)
4. Всех вышеперечисленных инстанций

Правила не с потолка взяты. Если у Васи Тютькина и Пети Пупкина один и тот же номер SSN, значит или он был занесен неправильно (что нужно исправить) или один из клиентов нам наврал про свой SSN (провести расследование). Если сотрудник банка забъет в качестве SSN какую-нибудь херню, то не позже чем через неделю этот "липовый" SSN всплывет в соответсвующем отчете, и будет проведено внутреннее расследование. Если ошибся сотрудник - "дадут по шее" если клиент предъявил липовую карточку - ему тут же закроют все счета, пока он не успел ничего натворить. Иначе клиент может навыписывать необеспеченных чеков, и ищи-свищи потом, не зная кто он и откуда. "Знай своего клиента" - аксиома в банковской деятельности. Банковская деятельность - это не игрушки. Требования к чистоте данных жесткие. За двух различных клиентов с одним SSN могут наказать, да притом так, что мало не покажется. И правильно делают, что наказывают. Иначе из банка будут деньги воровать.
7 окт 04, 20:08    [1017342]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
2 Зл0й : очень рад за сотрудника банка, который может кого хочешь послать очень далеко. Программы не только в банках работают.И чем меньше размер бизнеса, тем больше в системе хранится грязных данных. И малом бизнесе лучше иметь грязные данные, чем не иметь их вовсе.
7 окт 04, 21:47    [1017440]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Если нету требований по чистоте данных, и количество пользователей = 1, то можно вообще без БД обойтись, электронной таблицей. Но это - вырожденный случай. А в любой нормальной, не бардачной организации требования к чистоте данных предъявляют. Иначе это для организации оборачивается убытками. Вовремя не оплачен инвойс - штрафчик, два раза оплатили один и тот же инвойс - зря потратили бабки итп. Грязные данные - бесполезны. Они не помогают упростить и автоматизировать процесс, а наоборот его усложняют и запутывают.
8 окт 04, 06:00    [1017546]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Да и не в банке дело. Вопрос "философский" - работать в бардаке или работать организованно и по правилам. Каждый руководитель решает сам. Какова организация - такая и автоматизация ее. В конторе бардак - и в отделе автоматизации бардак. И наоборот.
8 окт 04, 06:03    [1017547]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Зл0й

Кстати в некоторых странах граждане почти всегда имеют право не светить свой SSN. Что делать в этом случае?
9 окт 04, 12:15    [1021248]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
В Западной Европе и США банк имеет право спрашивать у клиента SSN. Естественно он хранится в зашифрованном виде.
10 окт 04, 06:50    [1021601]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Зл0й

>В Западной Европе и США банк имеет право спрашивать у клиента SSN.

Во-первых банками бизнес не ограничивается, бывают работодатели и попроще, которые спрашивать тоже имеют право, но клиент (или работник) имеет право не ответить. Им тоже нужны БД сотрудников и клиентов.

Во-вторых "имеет право спрашивать" не значит "спрашивает обязательно".

Какой ПК должен появиться в БД если контора вдруг не спросит или человек воспользуется своим правом и откажется называть SSN?

>Естественно он хранится в зашифрованном виде.

Первичный ключ хранится в зашифрованном виде? Предположим это годится для внутреннего употребления, но ведь SSN нужен банку не просто как первичный ключ, банк по нему проверяет, например, credit history. Как можно по зашифрованному SSN проверить credit history, которая лежит совсем в другой организации и там он либо не зашифрован либо зашифрован другим алгоритмом?
11 ноя 04, 01:36    [1096773]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 30 31 32 33 34 [35] 36 37 38 39 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить