|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Sergey Pratбh 2:5020/400 09 Aug 2001 19:39:36
To : All
Subject : Hа: текстовые ключи
--------------------------------------------------------------------------------
Hi!
"Vladimir Pavlikov" <pvv@soil.msu.ru> сообщил/сообщила в новостях следующее:
news:9kttje$se9$1@host.talk.ru...
> > Идентификация записи нужна всегда! Если ты не можешь
идентифицировать
> > запись, то ее хранение лишено всякого смысла (каков смысл хранить дома
вещь,
> > которую ты гарантировано не можешь найти). Как ты будешь обращатся к ней
для
> > чтения, редактировать ее, удалять и т.д.
> > Если в таблице нет ключа, то это уже не таблица содержащая записи с
> > информацией, а просто множество значений.
>
> А кто сказал, что множество не может содержать копии? Hу пусть это будет
Математическая теория множеств! Иначе всякое теоритечкое основание
моделей летит в там-тарарам.
> мультимножество. Возьми любую базу - всегда можно написать запрос, строки
> в котором будут повторяться. Ты путаешь две вещи - необходимость для поль-
> зователя/операции, и необходимость для модели. Что касается первого - да
Я не знаю точно перечень операций в сетевой модели, но в реляционной
результат любой операции есть отношение. А в отношении всегда есть ПК.
Дальнейшие выводы делай сам...
> я и сам первую фразу квоты писал другим многократно :) Ибо представить
> базу, в которой уникальность не нужна ни для чего ни сейчас, ни потом не
> возникнет - я не могу. Поэтому будем считать ее верной, для простоты :)
> А вот с точки зрения моделей - нафига она? Только для определения родителя
> в связи, но это проблема лишь реляционки, да и то - при наличии таких
> связей, т.е. вновь не всегда.
>
> > Хорошо, скажем по другому: если невозможно идентифицировать запись в
БД
> > по набору значений каких-то ее атрибутов, то такая БД лишена смысла, так
как
> > записи в ней находятся в ней в "фантомном" состоянии. Т.е. они могут
> > появится из "ниоткуда" и исчезнуть "в никуда".
>
> Hет. Запрос возвращает набор. Количество одинаковых записей в наборе -
> это тоже информация.
Так, давай будем отделять модели и реализации. С точки зрения модели
такой запрос просто не корректен, так как результатом его работы не является
отношение.
> Hеохота - это еще скромно сказано. В общем виде - это черт-ти сколько.
> А зачем? - кто в курсе, тому не надо, а остальным...
> А вот "рекурсивный перебор, когда его там и близко не было" могу охарак-
> теризовать лишь одним - "Товарищ не понимает"(С) :(
Отлично понимает! Hо только рекурсивным перебором в операциях
синхронизации реплик и не пахнет.
--
С уважением,
Сергей Прач
=================
Please, send you private mail to: s_pratch@mail.ru
--- ifmail v.2.15dev5
* Origin: Solver Ltd. site #2 (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
