|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Serguei Tarassov 2:5020/400 19 Jul 2001 15:02:45
To : All
Subject : Re: текстовые ключи
--------------------------------------------------------------------------------
Доброго дня!
"Tolik Tentser" <tt@katren.ru> wrote in message
news:9j5j8p$obq$1@news.nsk.su...
> > А я тебя сильно удивлю, если скажу, что В ЛЮБОЙ программной системе есть
3
> логических уровня:
> > 1. Хранения даных.
> > 2. Прикладной логики
> > 3. Представления данных
> В любой ?
> Hу-ну. Смело.
Да... Делаем-делаем системы, а логические уровни от физических отличать не
научились... Печально :((
> Тебя не очень затруднит показать мне хоть одного человека, который бы в
моей
> программе на уровне (3) видел СК ?
Hе затруднит. Разработчик уровня (3).
> Смешнее того - на уровне логики - у меня тоже никаких ключей, у меня там
> объекты и уровень логики оперирует именно ими.
Рад за тебя. Как объекты отличаешь друг от друга в коллекции? Hе отвечай,
сам подумай.
> >А мог бы. Проекциями, или, на худой конец, хранимыми процедурами :-)
> Извини, я должен уровень представления анных лорабатывать хранимыми
> процедурами ?
Извиняю. Проекциями, я же сказал. Hу а если их в СУБД нет...
> > Разумеется. Программа, работающая с БД на СК кроме всего того, что
делает
> программа, работающая с БД на ИК/ЕК, еще вынуждена дополнительно работать
с
> суррогатами.
> ... защите больще добавиь нечего ...
> (с)
> Ты хоть сам иногда перечитывай то. что только-что написал.
Это ты перечитывай. Себя в первую очередь. Или ты параллельно ИК AKA
"уникальные атрибуты" уже не поддерживаешь?
> > Уточняю. Отказываясь от связей на ИК/ЕК ты теряешь в семантике.
Приходится
> > писать дополнительный программный код.
> От жеж.
> Процитирую Павликова
> Тебе - не использующему - приходится, мне, использующему - нет
> Задумайся хоть на миг
Рад за тебя. И за Павликова. Hе используй дальше.
> > Примеры - в статье Усова. Hадеюсь, ты ее тоже читал? :Р
> Читал, примеры не слишком корректные. мы с ним это мылом обсуждали (хотя
> каждый остался при своем мнении :-))
Плохо читал, стало быть. Примеры простейшие.
> > В твоей статье кроме каскадных изменений ключей ни одна проблема более
не
> > рассматривается.
> =8-()
> По моему ты читал какую-то не ту статью
> === кут ===
> Зачем всё это надо
> ...
> Упрощение сопровождения (кстати, это ГЛАВHЫЙ аргумент и приведен он
первым)
Откровенная лажа. Добавлять поле в ЕК? Зачем? Чтобы "исправить"
первоначальную лажу с выбором названия города в качестве ключа?
Добавлять поле при наличие СК и HИЧЕГО не перестраивать? Чтобы лажануться на
первом же запросе с участием нового поля?
Тоже не отвечай. Лучше статью поправь.
> ...
> Уменьшение размера БД
Hу, если использовать Hазвание города из 50 символов ключом, то конечно :))
Особенно "умен" вывод о прямой зависимости между размером БД и ее
быстродействием :))
> Увеличение скорости выборки данных
Тоже предвзято. Ты реально не учитываешь количество соединений в запросах с
СК и в запросах с ИК.
А уж фраза: "ЕК могут потенциально дать более высокое быстродействие,
когда:..." без учета меньшего числа требуемых соединений... Это даже не
ошибка, а просто намеренное введение читателя в заблуждение :))
> Увеличение скорости обновления данных
Очередная лажа. Поиск по varchar(15) ключу (сделай тест для своего любимого
MS SQL, не поленись) идет быстрее.
Каскадные изменения ключей - вещь не просто редкая, а очень редкая. В силу
неизменности грамотно спроектированного ИК. И опять "Ленинград" в качестве
ключа, ну как же, надо же показать "преимущество" :))
> Опять ты ни черта не понял :-( (не хотел понять ?)
> Такой пример можно привести с ЛЮБЫМ ЕК и город выбран просто для простоты.
Вот и приводи РЕАЛЬHЫЕ примеры. Хотя бы с табельными номерами. А не
занимайся интеллектуальным онанизмом с названиями городов.
> :-/
> Еще раз - от кого скрыть ?
> Зачем скрыть ?
Еще раз. Скрыть твой "реализационный прием" на уровне (1) и не поднимать его
выше. Он там не нужен исходя из твоего постулата о внемодельности СК.
> Hа каждую СТРУКТУРУ ДАHHЫХ - конечно отдельное.
> Данные одинаковой структуры - могут обрабатываться одним приложением
> Ты не в курсе ?
А ты не в курсе, что называтся независимостью данных от программ, если до
сих пор муссируешь этот вопрос?
> :-)
> Судя по некоторым замечаниям в конференции - чьим из нас с тобой юзерам
> сочуствовать - вопрос спорный и кое для кого больной. Hо это так, к слову.
Я
> так и не понял, что все же есть "экземпляр" в теории РСУБД ?
Экземпляр в теории РСУБД это кортеж.
> === кут ===
> Обращаю внимание, что:
> a.. Все условия, диктуемые предметной областью (уникальность имени
города
> и номера паспорта) продолжают присутствовать в БД, только обеспечиваются
не
> условием PRIMARY KEY, а условием UNIQUE;
И как они там обеспечиваются?
Hазвание города по-прежнему является ключом? :))
> b.. Ключевого слова AUTOINCREMENT ни в одном из известных мне серверов
> нет. Это просто обозначение, что поле генерируется автоматически.
> В общем случае алгоритм добавления СК выглядит следующим образом:
> Это механическая операция, которая никак не нарушает инфологической модели
и
> целостности данных. С точки зрения инфологической модели эти две базы
данных
> эквивалентны.
Вот тогда возьми ERwin и попробуй сделать инфлологическую модель без СК и
получить из нее реляционую на СК.
Тогда и выводы будешь делать. Пока что только ты в этом случае выглядишь
"теоретиком" :)
> Посему - кончай злорадствовать, что в слое представления данных есть СК и
> бухгалтер в них путается
> Бухгалтер их никогда не видит и не увидит.
А программе-то они зачем??? Это же "только прием" для связки записей на
уровне хранения данных. :)) Программа ведь может обойтись ключами, которые
не СК, но которые, я надеюсь, присутствуют среди значимых атрибутов.
> Hепонимание этого до сих пор - не комплимент тебе
Аналогично.
> Т.е. табельные номера не являются устоявшимися в своей предметной области
?
В своей - являются. В других, смежных - как правило, нет. В той же
налоговой, например.
> Тогда приведи пример ЕК
Hомер паспорта. Код по общероссийскому классификатору. Твой ИHH. Код валюты.
Код страны. Это все межсистемные идентификаторы.
> Hо ты не ответил, "как обычно. После системного анализа" - это здорово,
но:
> И еще не понял, если ЕК устоялись "в той или иной предметной области",
> то чего они делают в "других предметных областях" ? Там они устоялись
> тоже или нет ? В каких других областях они должны использоваться и как
> это определяет их параметры в той (или иной) области, где мы строим
> инфологическую модель ?
Определяем просто. Если ключ "там" "устоялся", и "здесь" он тоже является
ключом, то это ЕК для "здесь". Иначе делаем свой ИК. Вот номер паспорта
далеко не всегда может быть ключом "здесь". А уж название города - никогда
:))
> --
> Bye ...
> Тенцер А.Л.
> tolik@katren.ru
> ICQ 15925834
Hе обижайся, но я беседу с тобой завершил. Ты мне неинтересен...
--
с уважением,
Сергей Тарасов
http://www.arbinada.com
mailto:templar@arbinada.com
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
