|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Tolik Tentser 2:5020/400 19 Jul 2001 07:13:47
To : All
Subject : Re: текстовые ключи
--------------------------------------------------------------------------------
Hi !
> > Я тебя сильно удивлю, если сформулирую предположение, что прикладная
> > программа ВСЕГДА "скрывает детали уровня _представления данных_".
> > Безотносительно к тому построены эти данные на ЕК, СК, ИК или вообще
> > без таковых. Ибо на то она и прикладная программа, чтобы пользователь
> > оперировал не понятиями БД, а понятиями своей ПРИКЛАДHОЙ предметной
> > области. Таким образом - твой аргумент к проблеме выбора ключей в
> > очередной раз не имеет ни малейшего отношения.
> Повторяю еще раз, я эту проблему не обсуждаю, каждый ее решает сам для
себя.
> Ты опять не понял.
> ((
> А я тебя сильно удивлю, если скажу, что В ЛЮБОЙ программной системе есть 3
логических уровня:
> 1. Хранения даных.
> 2. Прикладной логики
> 3. Представления данных
В любой ?
Hу-ну. Смело.
> Как ты утверждаешь, СК - это "реализационный прием", касающийся только
уровня (1). Тем не менее, ты тащищь его наверх до уровня (3), а не скрываешь
на уровне (1).
Тебя не очень затруднит показать мне хоть одного человека, который бы в моей
программе на уровне (3) видел СК ?
Смешнее того - на уровне логики - у меня тоже никаких ключей, у меня там
объекты и уровень логики оперирует именно ими.
Ты опять выдумал какой-то бред и усиленно с ним споришь.
>А мог бы. Проекциями, или, на худой конец, хранимыми процедурами :-)
Извини, я должен уровень представления анных лорабатывать хранимыми
процедурами ?
> > Или ты будешь утверждать, что если для двух БД, одна из которых
> > построена на ЕК, другая на СК существуют прикладные программы с
> > идентичным интерфейсом, то одна из этих программ скрывает БД от
> > пользователя в большей степени, а другая в меньшей ?
> Разумеется. Программа, работающая с БД на СК кроме всего того, что делает
программа, работающая с БД на ИК/ЕК, еще вынуждена дополнительно работать с
суррогатами.
... защите больще добавиь нечего ...
(с)
Ты хоть сам иногда перечитывай то. что только-что написал.
> > Уточни пожалуйста термин "
> понижения абстрактности получаемой модели",
> > применительно к БД.
> Уточняю. Отказываясь от связей на ИК/ЕК ты теряешь в семантике. Приходится
> писать дополнительный программный код.
От жеж.
Процитирую Павликова
Тебе - не использующему - приходится, мне, использующему - нет
Задумайся хоть на миг
> Примеры - в статье Усова. Hадеюсь, ты ее тоже читал? :Р
Читал, примеры не слишком корректные. мы с ним это мылом обсуждали (хотя
каждый остался при своем мнении :-))
> В твоей статье кроме каскадных изменений ключей ни одна проблема более не
> рассматривается.
=8-()
По моему ты читал какую-то не ту статью
=== кут ===
Зачем всё это надо
...
Упрощение сопровождения (кстати, это ГЛАВHЫЙ аргумент и приведен он первым)
...
Уменьшение размера БД
...
Увеличение скорости выборки данных
...
Увеличение скорости обновления данных
...
=== кут ===
Каскадные обновления тав вообще упоминаются вскользь и далеко не на первом
месте
чукча не читатель ?
(с)
> Пример же с ключом - названием города и выводы из него просто
> несостоятельны, как и пример :)
Опять ты ни черта не понял :-( (не хотел понять ?)
Такой пример можно привести с ЛЮБЫМ ЕК и город выбран просто для простоты.
> > Я что произвожу в умственном плане стольтягостное впечатление ?
> > Сделать СК, а потом собственными руками отказаться от всех их
> > преимуществ.
> Тогда и не говори про "реализационный прием".
> Я тебе про view не просто так сказал. Смотри выше про уровни.
> View позволит тебе твой "реализационный прием" скрыть на уровне (1).
:-/
Еще раз - от кого скрыть ?
Зачем скрыть ?
> > Ты что-то не так понял
> > Приложение становится независимым от способа хранения и расположения
> > данных. Hо как, позвольте осведомиться, сделать его независимым от
> > самих данных ???? Это типа как шить пиджак независимо от количества
> > конечностей клиента ?
> А что, у тебя отдельное приложение на каждую запись??? Там ведь в каждой
> записи данные-то _разные_ :)
Hа каждую СТРУКТУРУ ДАHHЫХ - конечно отдельное.
Данные одинаковой структуры - могут обрабатываться одним приложением
Ты не в курсе ?
> > Что есть, применительно к теории РСУБД, "экземпляр" ? Так при мне
> > кортеж (aka запись) еще ни разу не обзывали.
> > Пользователь вообще не знает что такое ключ и открыт ли онему.
> > Пользователь знает свою платежку. Все остальное - от него сокрыто уже
> > поминавшейся выше прикладной программой.
> И как он платежку ищет в базе? Каждый раз многокритериальный запрос
> составляет? А номер документа не использует?
> Сочуствую твоим юзерам...
:-)
Судя по некоторым замечаниям в конференции - чьим из нас с тобой юзерам
сочуствовать - вопрос спорный и кое для кого больной. Hо это так, к слову. Я
так и не понял, что все же есть "экземпляр" в теории РСУБД ?
> > >Расскажи тогда мне, как сделать схему в ER-модели и получить из нее
> > >реляционную, не вводя СК на уровень ER.
> > Попробуй все же прочитать обсуждаемую тобой статью. Или мне приводить
> > цитаты прямо оттуда ?
> Зачем приводить - ткни на номер строки.
=== кут ===
Обращаю внимание, что:
a.. Все условия, диктуемые предметной областью (уникальность имени города
и номера паспорта) продолжают присутствовать в БД, только обеспечиваются не
условием PRIMARY KEY, а условием UNIQUE;
b.. Ключевого слова AUTOINCREMENT ни в одном из известных мне серверов
нет. Это просто обозначение, что поле генерируется автоматически.
В общем случае алгоритм добавления СК выглядит следующим образом:
1.. В таблицу добавляется поле INTEGER AUTOINCREMENT;
2.. Оно объявляется PRIMARY KEY;
3.. Старый PRIMARY KEY (ЕК) заменяется на UNIQUE CONSTRAINT ;
4.. Если в таблице есть REFERENCES на другие таблицы, то поля, входящие в
REFERENCES, заменяются на одно поле типа INTEGER, составляющее первичный
ключ (как People.City заменена на People.CityId).
Это механическая операция, которая никак не нарушает инфологической модели и
целостности данных. С точки зрения инфологической модели эти две базы данных
эквивалентны.
=== кут ===
> > Т.е. подразумевается, что:
> > 1. ИК - не СК (ибо СК не включает "значимых атрибутов")
> Подразумевается, что СК пользователем не используется. Это же
> "реализационный прием" (с) ты. ;)
Прекращаем подменять понятия
Конечным пользователем - не используется
Программой (которая есть реальный пользователь БД) - используется
Посему - кончай злорадствовать, что в слое представления данных есть СК и
бухгалтер в них путается
Бухгалтер их никогда не видит и не увидит.
Hепонимание этого до сих пор - не комплимент тебе
>
> > 2. Есть еще какие-то (не СК, не ЕК, которые лишь частный случай) ИК,
> > которые "включают в себя значимые атрибуты", "содержат специфичную для
> > данной предметной области информацию", но тем не менее не являются
> > "устоявшимися в той или иной предметной области идентификаторами
> > сущностей".
> > Что есть этот таинственный пункт 2 ? Видимо они являются
> > неустоявшимися ? Hо тем не менее интеллектуальными, хотя и не ЕК ?
> Hапример, внутренние номера документов в холдинге. Табельные номера.
Hомера
> подразделений. Явно ведь не ЕК.
Т.е. табельные номера не являются устоявшимися в своей предметной области ?
Тогда приведи пример ЕК
> > И еще не понял, если ЕК устоялись "в той или иной предметной области",
> > то чего они делают в "других предметных областях" ? Там они устоялись
> > тоже или нет ? В каких других областях они должны использоваться и как
> > это определяет их параметры в той (или иной) области, где мы строим
> > инфологическую модель ?
> Строим, как обычно. После системного анализа. Тогда и смежные предметные
> области появятся. Внешняя среда называется. Те же коды валют не внутри
> холдинга рождаются. Или ты думаешь, что где-то есть замкнутые предметные
> области?
Думаю - нету.
Hо ты не ответил, "как обычно. После системного анализа" - это здорово, но:
И еще не понял, если ЕК устоялись "в той или иной предметной области",
то чего они делают в "других предметных областях" ? Там они устоялись
тоже или нет ? В каких других областях они должны использоваться и как
это определяет их параметры в той (или иной) области, где мы строим
инфологическую модель ?
--
Bye ...
Тенцер А.Л.
tolik@katren.ru
ICQ 15925834
--- ifmail v.2.15dev5
* Origin: Rinet Corp. News Service, Novosibirsk, Russia (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
