|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Serguei Tarassov 2:5020/400 16 Jul 2001 14:17:10
To : All
Subject : Re: текстовые ключи
--------------------------------------------------------------------------------
Доброго дня!
"Tolik Tentser" <tt@katren.ru> wrote in message
news:9itueb$i2f$1@news.nsk.su...
> Для БД "пользователем" является клиентская программа и никто от неё ничего
> не скрывает.
> Если конечный пользователь напрямую работает с БД (что было характерно во
> времена, когда Кодд писал свои труды, но не очень характерно для текущего
> исторического этапа) - то опять же СК ему вполне доступны.
Доступны, но излишни.
> А насчет "открыты конечному пользователю" - посмотри любой современный
> генератор отчетов - во всех ни предусмотрена мощная поддержка метаданных,
> именно скрывающих от пользователя сложное устройство БД. С чего бы это ?
Они
> что все, Кодда не читали ?
Метаданные никак не связаны с конкретной моделью данных. Это как раз способ
от нее абстрагироваться. К Кодду отношения не имеют.
> > Скрывая СК ты действительно делаешь реализационный прием, который
> фактически
> > эмулирует сетевую модель на реляционной СУБД.
> Hичего подобного.
Аргументировать можешь?
Посмотри на запросы к сетевой БД в уже упоминавшейся статье
http://www.citforum.ru/database/digest/codd_1.shtml
Практически то же самое, что в запросах с СК.
Механизм установления связей между записями тоже идентичен.
> > Вопрос - а не лучше ли тогда взять сетевую СУБД (если не учитывать
> > коньюнктуру рынка, конечно)?
> Hе лучше, ибо незачем.
Тоже аргумент...
> > Грамотно спроектированный ИК тоже не меняется.
> Я же говорю, что ты ничего не понял.
> Это и есть базовая аксиома, от которой вы с Усовым строите все дальнейшие
> рассуждения. И вот её то я и полагаю неверной.
Это понятно. Так ведь и БД не вечна, и программист, и пользователь. А ежели
информация дорого стоит, вроде тех же почтовых индексов или международных
обозначений валют, то кто будет менять ее структуру "просто так"?
Полагаю, однако, что различие во мнении на эту "аксиому" сводит на нет все
дальнейшие обсуждения.
> > Тем не менее, в логической модели приходится их рисовать :(
> Зачем ????
Чтобы в физической (для реляционной модели) получить. В сетевой бы не
пришлось. Еще один косвенный аргумент.
> Hаследование реализовано HЕ на уровне БД, а на уровне сервера приложений.
> И проблемы ключей к нему не имеют абсолютно никакого отношения.
Тем не менее, есть унифицированная обработка по OID, и OID сквозной в
системе. Следовательно, все наследуемые persistent-классы на уровне
приложения имеют этот OID в качестве ключа в местах своего хранения.
> --
> Bye ...
> Тенцер А.Л.
> tolik@katren.ru
> ICQ 15925834
--
с уважением,
Сергей Тарасов
http://www.arbinada.com
mailto:templar@arbinada.com
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
