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

Откуда: Новосибирск
Сообщений: 2405
Блог
Андрей Леонидович
Andreww !

Пожалуйста, разберитесь сами, в библиотеке. Вот Павел Воронцов уже воспользовался этим моим советом. Ничего плохого в этом нет. Знания по многим аспектам теории БД действительно оказались утраченными. И только Вы сами можете восполнить этот пробел, по крайней мере в своих знаниях.

Сударь, не надо на меня кивать. Вы мне ничего не доказали (кроме своей интеллектуальной несостоятельности). Ни в какой библиотеке я не был и не разбирался. Не передёргивайте.
30 сен 04, 13:04    [999585]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 Коллега ЧАЛ ;)



>>Пожалуйста, разберитесь сами, в библиотеке. Вот Павел Воронцов уже воспользовался этим моим советом.

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




>>Знания по многим аспектам теории БД действительно оказались утраченными.

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

30 сен 04, 13:36    [999751]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
2 Андрей Леонидович

А где комментарии к тому что я для Вас написал жирным шрифтов в прошлом посте?
Два дня думали как ответить на вопрос про то, что своим утверждением
Уникальность ЕЩЕ ОДНОГО атрибута ... обеспечивает ТОЛЬКО уникальность этого атрибута фактически признали, что для ограничения уникальности нужен все-таки ключ, который якобы провалился? Ничего не придумали и решили "забыть" про это? Хорошая манера вести дискуссию для ученого.


>Итак, Вы нехотя признали, что пользователь ПРОСТО ИЗМЕНИТ НЕУДАЧНОЕ значение этого атрибута (дубликат атрибута), и ВСЕ РАВНО ВВЕДЕТ ТО, что хочет (и "это" может оказаться уже тысячным дубликатом сущности).

Значит ли это, что Вы считаете, что уникальность атрибутов не нужно использовать? Так прямо и скажите.

Про то, что сделает пользователь после того, как получит собщение об ошибке при попытки нарушить уникальнось атрибута, вроде речи не было. Если введет неверное значение, иказит - возьмет ответственность на себя. Его данные будут отличаться от документов и это можно обнаружить. Отвечать ему придется потом. А если найдет тот кортеж, который уже есть и разберется с ситуацией, то обеспечит достоверность данных. Важно, чтобы система не дала ввести дубликаты, поскольку тогда разобраться будет совсем сложно и приведет к дальнейшей эскалации уже плохо контролируемых ошибок. И ответственность ложится на разработчика - нельзя требовать от пользователя, чтобы он просматривал всю таблицу на предмет есть там такое значение или нет. От него даже не всегда можно требовать, чтобы он знал про то, что атрибут уникален. Т.е. держал в голове у себя ограничения целостности модели данных, и сам их вместо системы обеспечивал. Это еще хуже, чем обеспечение с помощью приложения.
Могу теперь себе представить Вашу систему и данные в Вней на предмет достоверности.

>Вы боитесь, что ДАЛЬШЕ (когда доберемся до SQL) РМД и РСУБД тоже могут оказаться в проигрыше ?

Умираю от страха. Аппонеты с такими методами вести дискуссию как у Вас - находка для защиты чего угодно.

>Я нашел одно такое пятно в туманном предположении Кодда (что заставило Вас выдвинуть еще одну революционную идею - Кодд не является автором РМД).
И кому я приписал авторствто? Надеюсь, не Вам. Вам бы поискать черную кошку в темной комнате, особенно если ее там нет. А Вы белые пятна ищете - явно не то, что у Вас хорошо получается.

>Пожалуйста, не упрямьтесь, на примере Ваших приложений:
В моих приложениях разумеется исплоьзуются ключи в обязательном порядке.
Первичные в любой таблице. Альтернативные во многих. Но проблема в том, что даже, если бы я не использовал или использовал не удачно - это ничего бы еще не доказывало. С точки зрения формальной логики - не полная индукция. Нужно чтобы никто не использовал или все применения были не удачными. Но и этого не совсем достаточно.
Зато я Вас спрашиваю конкретно о том как Вы обеспечиваете ограничение уникальности без ключей?
Если Вы не приводите ни чего лучшего чем ключи, то это значит, что ключи пока нужны. Не пользоваться же тем, что хуже?

В отличии от Вас я Вам не приписываю того, чего Вы не говорили. Но Вы своими рассуждениями про то, что объявление уникальности атрибута (объявление ключа) ТОЛЬКО для уникальности атрибута признали нужность ключа. Или Вы хотите сказать, что не нужно заботиться об уникальности атрибутов? Уточните.
Впрочем, я давно догадался почему с вопроса об идентификации Вы попытались перейти на ненужность ключей в РМД и их якобы провал.
Вы в своей системе давно от них отказались, и теперь хотите доказать всем и себе, что это не была ошибка. Напрасный труд. Вы еще откажитесь от зарплаты, и докажите нам чтобы и мы решили, что это хорошо. Нашли дураков отказываться от ключей? Потом надеетесь заставить нас отказаться от SQL? Потом от РСУБД и ОРСУБД? Потом от всех СУБД кроме Вашей? Вы работаете в отделе маркетига? Это рекламная компания Вашей системы? От того Ваши рассуждения такие технически наивные? Но пока Вы только делаете хуже для Вашей системы.
30 сен 04, 14:36    [1000049]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
osse
Member

Откуда: Н-ск
Сообщений: 162
Андрей Леонидович

Так какие еще белые пятна остались у нас в этой части: "Роль ключей в РМД и идентификаторов в ОМД" ?


Хотелось бы, краткий список "практических свойств" идентификаторов в ОМД.
Из всей дискуссии я понял, что таких свойств, отсутсвующих у "просто атрибута отношения", у идентификаторов в ОМД два:
------------
1. Идентификатор есть у каждой сущности, априори.
2. Значение,единожды присвоенное идентификатору сущности, неизменно.

Соответственно, эти два свойства, позволяют Андрею Леонидовичу делать утверждения о том что:

1. Идентификатор не зависит от описания сущности.
2. Ссылка на идентификатор целостнее чем ссылка на атрибут.
------------
Хотелось бы, еще, услышать о том как решается (?) в ОМД (с помощью идентификаторов?) проблема, обсуждаемая в последнем "диапосте" Андрей Леонидович - vadiminfo, о вводе "дубля" сущности с "неправильным" значением ключевого атрибута.
30 сен 04, 20:51    [1000695]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
vadiminfo !

Я очень точно и подробно высказался по поводу уникальности атрибутов при уже объявленных идентификаторах (суррогатах в РМД). Привел мысли Кодда по этому поводу. И предложил Вам и всем остальным проанализировать мысль Кодда о ключах, поддерживаемых пользователями. И доказать хоть какими-то фактами, что нет полного провала ключей, функциональных зависимостей и теории нормализации в РМД.
Какие еще "его данные будут отличаться от документов" ? Что значит "и обеспечит достоверность данных" ? Почему "важно, чтобы система не дала ввести дубликаты" (атрибута !) ? Почему конкретно не достаточно суррогата ?

Почему Вы не хотите обсуждать вопросы по-существу ?

Пожалуйста, не упрямьтесь, на примере Ваших приложений:

1) насколько often;
2) в каком смысле totally;
3) характерность примеров ("базовый" - part serial number);
4) о каких именно ключах (все-таки - это реляционная модель, и entity identifiers - это ключи), предположительно, идет речь:

- о "теоретических" потенциальных;
- о "практических" первичных;
- о "практических" альтернативных.

Ведь отвечая на эти вопросы, Вы покажете, наконец-то, какие-то загадочные, фантастические примеры уникальности, о которых все время намекаете, и в которых, якобы, что-то не понимаю я, из-за своего невежества.
30 сен 04, 22:39    [1000751]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Павел Воронцов !

Как-то невесело Вы сказали, что ни в чем не хотите разбираться.
Извините, нем не менее, я думал - хотите...
30 сен 04, 22:42    [1000753]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Andreww !

Так Вы и так все знаете, но скрываете ?

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

Пожалуйста, не скрывайте (нет же, я надеюсь, в этом никакой военной тайны), на примере Ваших приложений:

1) насколько often;
2) в каком смысле totally;
3) характерность примеров ("базовый" - part serial number);
4) о каких именно ключах (все-таки - это реляционная модель, и entity identifiers - это ключи), предположительно, идет речь:

- о "теоретических" потенциальных;
- о "практических" первичных;
- о "практических" альтернативных.

Ведь отвечая на эти вопросы, Вы покажете, наконец-то, какие-то загадочные, фантастические примеры уникальности, в которых, якобы, что-то не понимаю я, из-за своего невежества.
30 сен 04, 22:46    [1000757]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
osse !

Во всех случаях (первичный ключ, суррогат, идентификатор, суррогат + альтернативный ключ) дубликаты сущностей будут введены. Это очевидно.

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

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

1) насколько often;
2) в каком смысле totally;
3) характерность примеров ("базовый" - part serial number);
4) о каких именно ключах (все-таки - это реляционная модель, и entity identifiers - это ключи), предположительно, идет речь:

- о "теоретических" потенциальных;
- о "практических" первичных;
- о "практических" альтернативных.

Я считаю, что всегда ясно высказывался о всех аспектах темы "Роль ключей в РМД и идентификаторов в ОМД". Причем вторая часть темы не представляет особого интереса, так как ОМД очень хорошо формализована: идентификатор:

- автоматически идентифицирует экземпляр;
- автоматически и явно отделяет сущность от описания.

О возможном использовании уникальных характеристик я высказался вполне определенно. Очевидно, что их роль отличается от роли ключей в РМД и суррогатов в РРМД. Но, вполне возможно, совпадает с ролью ДОПОЛНИТЕЛЬНЫХ (даже альтернативными их назвать нельзя) ключей (помимо суррогатов) в РРМД.

Кажется спор о роли ключей в РМД достиг критической точки. Возможно нам потребуется еще не раз пройти по кругу, но полный провал ключей, функциональных зависимостей и теории нормализации в РМД мне доказать удастся.
30 сен 04, 23:11    [1000770]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
vadiminfo !

Это Вы про что ?:

"Я тоже так считал пока разрабатывал небольшие по объему БД на Access. и избегал суррогатных ключей. Но приходится признать, что в больших БД желательно избежать изменения значений первичного ключа. Особенно если это грозит каскадным обновлением. Кроме того, возникает проблема стиля при написании триггеров. Т.е. если в одном случе суррогат, а в другом естественный ключ, то ухудшает стиль."

То есть не лукавить, и говориьть по-существу Вы можете, но только не со мной ?
30 сен 04, 23:50    [1000796]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
2 Андрей Леонидович

>Я очень точно и подробно высказался по поводу уникальности атрибутов при уже объявленных идентификаторах (суррогатах в РМД).



Но это означет, что ключи нужны для обеспечения уникальности ТОЛЬКО этого атрибута. Т.е. они нужны.

Об этом был Вам вопрос. Ответа не нашел.

Я даже не больше обращаю Ваше внимание, что идентификаторы первичные ключи хоть суррогатные, хоть естественные все равно ключи в РМД. Т.е. получается, что и они нужны раз они уже объявлены до уникальности ТОЛЬКО этих атрибутов.

Тогда о каком провале ключей идет речь, если они нужны? И что Вы понимаете тогда под словом "провал"?

Вы робко попытались выкрутиться с примером про НЕ ПРАВИЛЬНЫЕ значения, но из этого последовало предположение, что ВЫ не считаете нужным вообще обеспечивать ограничение уникальности для ТОЛЬКО этих атрибутов. Об этом был вопрос. Ответа в вашем посту не нашел.

А это важно. Это ограничения целостности -важная часть любой модели, кроме, наверное, ВАшей.

>И предложил Вам и всем остальным проанализировать мысль Кодда о ключах, поддерживаемых пользователями.

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

>И доказать хоть какими-то фактами, что нет полного провала ключей, функциональных зависимостей и теории нормализации в РМД.

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

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

>Почему конкретно не достаточно суррогата ?
А суррогат вообще мало о чем говорит пользователю. Он лучше для связи с другими таблами, для программной идентификации. Т.е. он как и OID не создается пользователнем, генерится системой (но в отличии от OID не обязательно, а по решению проектировщика БД). И может возникнуть двусмысленная ситуация, когда с разными суррогатами пользователь внес два кортежа, соответствующих одной реальной сущности. Например, одного и того же человека. Т.е. кортежи не идентичны по суррогатному атрибуту, но равны по естестественным атрибутам.

Мы говорили с Вами об этом? Забыли? Что из-за этого OID и в ООМД не достаточно. Т.е. для того, чтобы пользователи могли различать объекты там тоже нужны ключи, но на естественных атрибутах.
Т.е. пока Вы пытаетесь заниматься провалом в РМД, а, возможно, Вам предстоит еще заняться их провалом и в ООМД и даже в Вашей ОИМД или просто ИМД - пока не знаю.
1 окт 04, 00:57    [1000835]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Андрей Леонидович

>Где Вы видите бред в следующих один за другим 6-пунктах и двух ограничениях (приведены в ЭТОЙ ДИСКУССИИ) ? А ведь это изложение ЧАСТИ моего доклада от 1999г. , который Вы называете полным бредом.

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

Не нужно философии, первичных ключей и идеализма с материализмом. Это слишком сложно. Оветьте на простой вопрос, который я вынужден повторять уже в пятый раз:
На каких страницах сжатого изложения Вашего доклада на семинаре или на каких страницах нашей дискуссии находятся эти самые 6 пунктов и два ограничения, о которых нужно высказать свое мнение?

НА КАКОЙ СТРАНИЦЕ? ГДЕ ИМЕННО можно прочитать эти 6 пунктов и два ограничения?
1 окт 04, 01:48    [1000850]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2405
Блог
Андрей Леонидович
Павел Воронцов !

Как-то невесело Вы сказали, что ни в чем не хотите разбираться.
Извините, нем не менее, я думал - хотите...
Спасибо, тут я уже во всём разобрался.
1 окт 04, 06:57    [1000940]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2405
Блог
c127
2 Андрей Леонидович

>Где Вы видите бред в следующих один за другим 6-пунктах и двух ограничениях (приведены в ЭТОЙ ДИСКУССИИ) ? А ведь это изложение ЧАСТИ моего доклада от 1999г. , который Вы называете полным бредом.

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

Не нужно философии, первичных ключей и идеализма с материализмом. Это слишком сложно. Оветьте на простой вопрос, который я вынужден повторять уже в пятый раз:
На каких страницах сжатого изложения Вашего доклада на семинаре или на каких страницах нашей дискуссии находятся эти самые 6 пунктов и два ограничения, о которых нужно высказать свое мнение?

НА КАКОЙ СТРАНИЦЕ? ГДЕ ИМЕННО можно прочитать эти 6 пунктов и два ограничения?
osse нашел - это здесь. Андрею Леонидовичу влом повторить ссылку. Страница 25. Но там всё равно бред.
1 окт 04, 07:09    [1000945]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Зл0й
Member

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

Оюъясните мне пожалуйста зачем нам городить идентификатор/суррогатный ключ в этих случаях:

- Есть книжка, у нее заведомо уникальный ISBN
- Есть изделие, например ПТРК, и заведомо уникальный номер (9К119 "Рефлекс", 9К117 "Бастион")
- Есть налогоплтельщик с заведомо уникальным ИНН

Зачем нам в этих случаях суррогатный ключ? И головняк по обеспечению 1:1 между суррогатным и натуральным ключем нам зачем?
1 окт 04, 07:40    [1000960]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Был я знаком с одним мужичком, в годах уже, который работает ведущим программистом в одной конторе. У него была мания величия - он считал, что самое лучшее - это то, что он придумал, а все остальное г.. :) Поэтому работая на Access, он не признавал правил нормализации форм и SQL (правильнее будет сказать так и не смог психологически переменить стиль программирования) и изобрел собственную технологию хранения и работы данных - вместо того, чтобы нормализовывать данные по множеству таблиц, хранил их в BLOB-ах :) А что, замечательно:
КодДоговораНомерДоговораКодыУслугСуммыУслуг
11"1;2;3;4;5""100.00;200.00;300.00;400.00;500.00"

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

Как известно в своей "изобретенной" технологии самое главное доказать миру, чем она лучше существующих и найти последователей. Если программисты не хотели становиться последователями и крутили пальцами у виска, то значит их смело можно было обвинять неучами и дураками, не понимающими своего счастья. Выглядело "приобщение" программистов к супер-технологии хранения данных в виде текста с разделителем, гордо именуемой технологией списков так: для принимающегося на работу молодого программиста сразу же показывали на того мужичка, обьявляя что он не только чиф для программиста, но так же непризнанный гений и человек, собственными руками сделавший уникальную технологию. "Непризнанный гений" во время этой речи руководства сидял с раздувающимися ноздрями и гордым видом старого прожженного волка. Далее новичку предлагалось сделать на Access тестовое задание до следующего дня и в принципе все заканчивалось мирным чаепитием и общением, где "старый волк" сидел молча и, причавкивая, хлебал чай, плотоядно поглядывая на новую, ничего не подозревающую "жертву". Все самое интересное начиналось на следующий день, когда молодой приносил сделанное тестовое задание. Критиковалось все в пух и прах, начиная от решения по неправильной постановке (вопросы по типу того, что именно такая постановка давалась для решения поставленной задачи не принимались) и до высмеивания самого решения. Выглядело это так: "Молодой человек, зачем Вы данные разбили по нескольким табличкам, да еще и соединили их FOREIGN KEY. Ууу, да Вы еще и в SQL пользуетесь LEFT JOIN - какой непроффесионализм, этого же нельзя делать.". Ну и в таком же духе. Естественно "молодой человек не вьезжал", что именно не нравиться местному "сан сэю" и соотвествующе немножно раздраженно интересовался, а как же интересно знать все это было бы нужно сделать. Вот тут то и наступал "момент славы" - торжественно провозглашался гибельный принцип буржуазного РМД, нормализации форм и SQL, и непосвященного начинали вводить в процесс постижения точек с запятой и работы через массивы. Причем обоснование отказа от нормализации форм было очень простым и наглядным: Они же требуют создания индексов, брызгая слюной в курилке доказывал "сан сэй", индексы занимают место, чтобы обрабатывать потом такие данные, нужно еще использовать этот глупый никчемный SQL. Я как то раз "по доброму" ему заметил, покуривая с своими ребятами в сторонке и слушая весь этот бред, который он нес для сотрудников своего отдела, что индексы не так уж много места занимают, в отличие от BLOB-ов, заставив его минут на 10 задуматься над интересным и новым для него вопросом за 5 лет работы с Access-ом - а как это в нем BLOB-ы то хранятся ?

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

P.S. Он кстати до сих пор работает в этой конторе и насколько я уже слышал, пытается проецировать свои списки на MSSQL, так как Access на BLOB-ах сильно быстро разбухает БД до 2 гб, с последующим их обрушением. Теперь вот насилует бедный MSSQL :)
1 окт 04, 08:04    [1000990]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
vadiminfo !

А Вам и не нужны никакие ответы. Вы их и не пытаетесь искать. Вы же имеете свое мнение, и отстаиваете его. Вы не робко, а совершенно откровенно игнорируете факты даже из собственной практики, в попытках доказать, что нет провала ключей, функциональных зависимостей, теории нормализации в РМД. Откровенно игнорируете мысли Кодда и Дейта (автора и наиболее последовательного сторонника РМД) о роли ключей. Отвлеченно рассказываете о каких-то документах. А когда, единственный раз, привели пример отношения, то, конечно же, полностью с ним провалились. И продолжаете говорить просто все, что в голову придет, например, про поезд и билеты. А на вопрос "Почему конкретно не достаточно суррогата ?" следует стандартный аргумент про двусмысленность ситуации.
Вот давайте и разберемся с ЧЕЛОВЕКОМ. Конкретно. Что Вы там предлагаете помимо суррогата ? А ведь я намекал на стандартные примеры (мировая проблема идентификации личности)...
1 окт 04, 11:58    [1001928]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
ЗлОй !

Очень хорошо ! Пошли конкретные примеры, но, к сожалению, это еще далеко не статистика, и мало конкретики и точности.

1. С ISBN ошибаетесь. Нет его у многих книг, и, следовательно, его нельзя использовать в качестве первичного ключа.
2. Не думаю, что это грамотное решение.
3. Может быть. Но примера конкретного приложения опять же нет.

Я ведь никогда не говорил, что в "Р"СУБД (!) не следует использовать определяемые пользователем первичные ключи. Я задал конкретные вопросы по принципам использования ключей и примерам. И обратил внимание, что, скорее всего, все будут приводить одни и те же "мировые" примеры ситуаций с ключами, "определяемыми" пользователями...
1 окт 04, 13:21    [1002058]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
ASCRUS !

Этот человек, возможно, разрабатывал нечто подобное вложенным отношениям в О("Р")СУБД Oracle. Задолго, насколько я понимаю, до Oracle. Я свое отношение к подобным разработкам высказал. Вы с какой целью рассказали об этом человеке ?
1 окт 04, 13:26    [1002072]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
>А Вам и не нужны никакие ответы.
Вы просто решили, что они мне не нужны и поэтому не отвечаете? А я парился писал вопросы, выделял жирным шрифтом, потому что именно это мне не нужно? Зато что мне точно нужно по Вашему так это Ваши голословные, сенсационные утверждения, к которым у меня возникает много не нужных мне вопросов?

>Вы их и не пытаетесь искать.
Да уж делал такое одолжение ВАм - искал. Хотя могли их и не прятать. Все-таки Вы не авторитет пока в инфотехнологиях, чтобы искать в Ваших текстах.

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



Я нигде не объявлял, что собираюсь это доказывать, тем более даже не знаю что есть по-вашему "ПРОВАЛ". Их важность доказали, до меня. А Вы признав, что они нужны для "уникальности только ЭТОГО атрибута" признали их нужность вообще. И что теперь доказывать? Получается, что доказана их польза.

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

>Отвлеченно рассказываете о каких-то документах.

Аккуратно отвечаю на Ваш вопрос, напрасно, надеясь на то, что и Вы так же сделаете.

>А когда, единственный раз, привели пример отношения, то, конечно же, полностью с ним провалились.
Это когда с вопроса о ключах Вы решили перескочить на анализ предметной области, чтобы не отвечать? Так я выбросил интерпритацию ради формализации (строгости) вопроса, чтобы Вы не отвлекались. Не помогло. Вы не ответили.

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

>А на вопрос "Почему конкретно не достаточно суррогата ?" следует стандартный аргумент про двусмысленность ситуации.

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

Вот давайте и разберемся с ЧЕЛОВЕКОМ. Конкретно. Что Вы там предлагаете помимо суррогата ? А ведь я намекал на стандартные примеры (мировая проблема идентификации личности)...
Это надо понимать как то, что с ролью ключей для ограничений целостности мы разобрались? Они нужны хотя бы для "уникальности ТОЛЬКО этого атрибута".
Или что? Теперь проблемами только идентификации заняться хотите?
А как же функциональные зависимости и нормализация: они с проблемами идентификации мало связаны. Там структуризация, ограничения целостности все больше просматриваются.
1 окт 04, 13:48    [1002137]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
>ASCRUS !

Этот человек, возможно, разрабатывал нечто подобное вложенным отношениям в О("Р")СУБД Oracle. Задолго, насколько я понимаю, до Oracle. Я свое отношение к подобным разработкам высказал. Вы с какой целью рассказали об этом человеке ?

Ваша недогадливость может произвести впечатление на кого угодн. Не хотите исакть? Помогу. Это человек реализовал Вашу мысли о провале нормализации на практике. Вплоть до 1НФ.
1 окт 04, 14:15    [1002195]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
В двух последних постах забыл в начале указать:

2 Андрей Леонидович.
1 окт 04, 16:20    [1002760]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
vadiminfo !

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

Users will often need entity identifiers (such as part serial numbers) that are totally under their control...

Подключайтесь, пожалуйста, на примере Ваших приложений:

1) насколько often;
2) в каком смысле totally;
3) характерность примеров ("базовый" - part serial number);
4) о каких именно ключах (все-таки - это реляционная модель, и entity identifiers - это ключи), предположительно, идет речь:

- о "теоретических" потенциальных;
- о "практических" первичных;
- о "практических" альтернативных.

И, в частности, про Человека (Сотрудника ?) очень интересно узнать. Это ведь, как раз, "характерный пример".
1 окт 04, 17:19    [1003060]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
2 Андрей Леонидович
Вы сначала объясните то, что я спрашивал. Без этого я вообще не могу найти никакого здравого смысла в Ваших словах. То провал ключей, то ключи нужны. Вы сами не знает чего хоЧИТе. И что тогда такое провал? Вы уж как нибудь определитесь. Вы обещали доказать провал, но никакие примеры не могут быть доказательством этого - не полная индукция перечислением. Где гарантия, что нет удачного примера, которого мы не видели? Вот если Вы говорите, что не нужны, то достаточного одного примера, где нужны (Всеобщее утверждение доказать сложнее, чем опровергнуть). Вы подтвердили, что нужны для "уникальности ТОЛЬКО этого атрибута". После этого не ясно вообще, что Вы доказываете. Вас просили разъяснить про провал.

>Внимательно читаю высказывания участников дискуссии по всем темам форума

Вы бы еще в этой теме читали бы, и приводили цитаты и комментировали. Как это делал я с Вашими постами. А так Вы не отвечаете, и не ясно вы согласились с конкретными высказываниями или что? Если согласились, то что доказываете? Если нет, то с чем? Вы единственный на этом форуме пока кто ведет себя так по детски. Я ведь тратил время в расчете на ответ, а не на детские игры кто кого переврет.

>Подключайтесь, пожалуйста, на примере Ваших приложений
Не смешите меня. Вы дискредитировали себя своими безответственными высказываниями, а теперь говорите так как будто Ваш авторитет опытного признанного проектировщика не вызывает ни малейших сомнений. Тем более приложений. А мы здесь про БД говорим. В них то Вы себя не очень подкованным показали (в ограничениях целостности совсем не разбираетесь да и в целом в моделях данных), и теперь на попрыще приложений себя решили попробовать? А главное ВЫ еще не объяснили Ваших прошлых опусов и не ответили на вопросы.
1 окт 04, 20:04    [1003451]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Зл0й
Member

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


Очень хорошо ! Пошли конкретные примеры, но, к сожалению, это еще далеко не статистика, и мало конкретики и точности.

1. С ISBN ошибаетесь. Нет его у многих книг, и, следовательно, его нельзя использовать в качестве первичного ключа.
2. Не думаю, что это грамотное решение.
3. Может быть. Но примера конкретного приложения опять же нет.

Я ведь никогда не говорил, что в "Р"СУБД (!) не следует использовать определяемые пользователем первичные ключи. Я задал конкретные вопросы по принципам использования ключей и примерам. И обратил внимание, что, скорее всего, все будут приводить одни и те же "мировые" примеры ситуаций с ключами, "определяемыми" пользователями...


1. ISBN у книг, выпущенных издательствами, есть всегда. Нету его у институтских методических пособий, и иных документов выпущенных "на коленке". Кроме отсутствия ISBN у этих недо-книг есть еще очень много отличий от "настоящих книг". Не все то что напечатано и переплетено, является книгой. Наиболее логичным, последовательным (и ИМХО грамотным) решением в смысле СУБД будет хранить "книги" и "не-книги" отдельно, ибо атрибуты у этих сущностей разные. Причем это будет правильно вне зависимости от того какая у нас модель представления данных, реляционная или объектная.

2. Мне, как программисту БД, совершенно не интересно грамотное решение принял ВПК бывшего СССР или нет, когда придумывал свою номенклатуру. Реально она такая какая есть, и другой не дано. Очень грубо говоря 9К - ракета, 117 и 119 "какая именно". Глупо обижаться на мир за то что он не согласуется с нашими теориями.

3. ИНН (Идентификационный Номер Налогоплательщика) в любом приложении будет находиться в отношении 1:1 к налогоплательшику. Это не программисты - сторонники реляционной модели придумали, а законодатели. К США и Западной Европе тоже есть номера социального страхования и налогоплательщика, уникальные по определению. У одного знакомого француза вышла путаница с номером, по ошибке на него завели 2 номера. Все что было начислено на старой работе, осталось висеть на "старом" номере. Образовался очень серьезный головняк. По уму, французский чиновник должен был просечь тот факт что Жан-Мишель Сери родившийся 12 ноября 1970 г. в Лионе и имеющий номер Х скорее всего то же лицо что и "Жан-Мишель Сери родившийся 12 ноября 1970 г." и обращающийся за новым номером. Поскольку вопрос не простой (чем черт не шутит, теоретически могли полные тезки родиться в тот же день в том же городе) то он требует того чтобы его решал человек. Соответственно сложный вопрос об уникальности решает человек, с помощью телефонных звонков, просмотра документов, и недоступного машине мыслительного процесса. Этот натураный (присвоенный человеком) ключ заведомо "правильнее" любого суррогата, тупо и злобно присвоеного машиной, безо всякого мыслительного процесса.
1 окт 04, 21:04    [1003511]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Павел Воронцов

>osse нашел - это здесь. Андрею Леонидовичу влом повторить ссылку.

Я уже нашел. Но мне хотелось бы услышать номер страницы именно от Андрея Леонидовича. Во-первых есть большие сомнения, что он знает, где находятся эти разнесчсатные 6 пунктов, им же сформулированные, а во-вторых, чтоб у него не было возможности потом съехать, заявив, что ссылку дал не он и это вообще не те пункты, которые он имел ввиду.

К тому же этот момент интересен в контексте заявления Андрея Леонидовича о том, что он-то как раз на все вопросы отвечает (Андрей Леонидович> Я то, как раз, на все вопросы отвечаю).

Хотя может просто вопросец пустяковый: подумаешь, страницу указать. Если бы что-нибудь позаковыристей, ну там про пространство и время как всеобщие формы существования материи и сознания или про объект как все противостоящее субъекту, вот тогда бы Андрей Леонидович рубанул бы с марксистко-ленинскийх позиций. А так чего размениваться по мелочам, масштаб не тот.
2 окт 04, 01:52    [1003756]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 29 30 31 32 33 [34] 35 36 37 38 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить