guest_20040621> Это вы на что намекаете ? :-)

Это я пока практически еще и не начал намекать. ;)

> Рекурсивность и древовидность сильно гадят, а так - не жалуюсь.

Практически счастливый человек. ;)

ОК, давайте попробуем решить традиционным образом такую задачу: путь в базе данных есть некоторая сущность, которая может быть связана с любой из других сущностей этой же базы данных отношением n:m. Какую бы схему Вы реализовали? (hint: база данных среднего размера, единицы сотен таблиц; hint2: таких сущностей в общем случае большей одной).

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

adiskПо моему скромному мнению данные надо хранить так как удобно для
компьютера, а представлять их так как удобно человеку.
То есть планировать, проектировать базу и работать с объектами.
Но хранить в виде удобном для обработки компьютером.

Золотая середина мне представляется в "ОО модели над РБД".
В чем и хочу посоветоваться с Вами, уважаемые...

Что-то вас мотает из стороны в сторону. То бросаетесь революцию в индексном деле устраивать, то изобретаете очередной "универсальный справочник всего", теперь вот в ООБД ударились... Про них уже насоветовали в соседнем разделе аж на 36 страниц.
Пока что ваши идеи и произведения принадлежат k разряду "компьютерной графомании". Мой вам добрый совет - поработайте с одной из серьезных баз (Оракл, MS SQL, Informix, DB2, Sybase), почитаете документацию, особенно главы про внутреннее устройство - и тогда приходите с идеями. А сейчас лучше не надо. Чтобы не было мучительно стыдно потом, поскольку форум-то нестираемый, и глупости, высказанные публично, имеют свойство всплывать в самый неподходящий момент.
Ну и запрос - я таки жду запрос. Мне очень интересно, как вы сделаете
- join между таблицами
- sum по текстовому полю
- "транспонирование" результата, чтобы две отдельных строки (сумма и описание покупателя) превратились в две колонки в результирующей таблице.

ShtockСам же говорил, флейма не начинать, НО: решение неприемлемо в случае, если в постановке задачи указано "система должна не зависеть от СУБД". В общем виде - так оно и есть в общем виде: использовать словарь БД. Понятно, что в каждой БД он разный, но БД без словаря не бывает -:)

Магические слова : SQL 92.
Чтобы решение было независимо от субд, используйте только средства, входящие в стандарт - и будет вам щасте.

adisk автор
Мой вам добрый совет - поработайте с одной из серьезных баз (Оракл, MS SQL, Informix, DB2, Sybase), почитаете документацию, особенно главы про внутреннее устройство - и тогда приходите с идеями. А сейчас лучше не надо. Чтобы не было мучительно стыдно потом, поскольку форум-то нестираемый, и глупости, высказанные публично, имеют свойство всплывать в самый неподходящий момент.

Чего мне стыдится?
Того, что я не дошел до Вашего уровня, уважаемый?
Излагая свое мнения, я ищу единомышленников. Или обоснованную критику.
Если Вы такой граммотный умный человек объясните мне простой способ хранения данных с произвольными свойствами.
Метаясь из стороны в сторону, я использую страрые проверенные реляционные БД, но ищу лучшие варианты. Лучшие способы хранения и обработки данных.
Жизнь не стоит на месте и с этим Вы не можете не согласиться.


Стыдиться надо неряшливости мышления. Вы систему придумали, а протестировать ее даже на самом простом случае не удосужились - прибежали на форум "советоваться".
Не говоря уж о том, что вы почему-то считаете ваш подход чем-то новым, типа "жизнь не стоит на месте". Поиск в Инете вы тоже не соизволили выполнить. Ну и получите критику, как заказывали.

adisk автор
Ну и запрос - я таки жду запрос. Мне очень интересно, как вы сделаете
- join между таблицами

Так же как и раньше. Операция пересечения множеств изменилась, что ли?


Для вас -да. Вы же все таблицы слили в одну - вот и изобразите нам операцию пересечения множеств в вашей "постреляционной" алгебре.

adisk автор
- sum по текстовому полю

Думаю, Вы ошибочно полагаете, что я собираюсь хранить все данные в одном ТЕКСТОВОМ поле? Сказывается многолетняя работа с таблицами вроде DBF, где поля строго типизированы.
А вы думали как таблицы хранятся на диске или в памяти? там есть тип?


Как данные хранятся на диске - я не думаю, я знаю. Мне интересно, как ВЫ их собираетесь хранить, а главное - обрабатывать. Поскольку чтобы обработать, субд должна знать, что именно там хранится. Традиционно это организовано как таблица syscolumns, где есть поле "тип колонки". Выши предложения ?
Или ваша система в принципе не реализуема на существующих СУБД, а представляет собой некий маниловский проджект ?

adisk
Замечу, что ОО поверх СУЩЕСТВУЮЩИХ РБД сделать сложно. (как раз из-за таких ограничений)


То, что вы предлагаете ("универсальный справочник") никоим боком не касается ООБД.

adisk автор
- "транспонирование" результата, чтобы две отдельных строки (сумма и описание покупателя) превратились в две колонки в результирующей таблице.
Как прикладная программа Вам показывает на экране таблицу (Grid, browse или еще что...)
Какие чудеса происходят с данными полученными от SQL-сервера или считанными с диска?
Никаких. Отображение информации нужном месте в нужное время.
что в этом сложного?
Вы справшиваете как сделать это средствами MS SQL или Oracl?

Именно. Я именно это и спрашиваю. Нарисуйте мне запрос, чтобы я мог его запустить из excel и получить вместо вашей длинной и узкой таблицы - широкую и короткую, как этого хотят все нормальные пользователи.

guest_20040621> Ок, давайте вы мне расскажите реальную постановку, а я вам расскажу, почему
> некая "сущность, связанная отношением м:н к любой другой сущности" вам нахер
> не нужна.

Да нет проблем. Например, есть словари. Толковый, технический, иностранный, - неважно, может, их несколько или они все вместе. Например, есть стандарты, согласно которым проектируются структуры данных. Две сущности - достаточно? Буквосочетание "семантик веб" ни о чем не говорит?

Приведенный пример как бы не совсем то, что я описал (т. е. отношение будет иметь смысл не для всех сущностей, а, скажем, для половины), но глобально это ничего не меняет.

На самом деле задача абсолютно реальна. И "нахер нужна". Приводить ТЗ я не буду, - незачем, и денег оно стоило, придется верить на слово. Замечу однако, что решение у этой задачи есть.

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

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

> Если есть все-таки желание их хранить, то я в своих задачах выявляю
> стопроцентные атрибуты и выношу их как поля в таблицах, а если должны
> появиться вспомогательные новые, то делаю поле типа XML, там все и храню.

Это Ваше решение. На мой взгляд, оно не оптимально. Вы не сможете манипулировать атрибутами, описанными в xml полях так же, как и "стопроцентными" атрибутами. Да и СУБД, поддерживающие т. н. "xml поля" можно по пальцам одной руки перечесть. ;)

> Магические слова : SQL 92.
> Чтобы решение было независимо от субд, используйте только средства,
> входящие в стандарт - и будет вам щасте.

Крайне важное замечание. ;)

1. Попытайтесь не приписывать мне чужих цитат.
2. Сочетание "семантик веб" мне ни о чем не говорит
3. "Техзадание стоит денег" - это пять ! "У нас есть такие системы, но мы вам о них не расскажем" :-) Ну хоть суть-то проблемы изложить можете ? Что там со словарями не втискивается в релятивистскую модель ? Отношение "слово - значение", что ли ? Типа слово может иметь много значений, и значение может описываться синонимами ? Так это стандартное отношение м:н, разрешается вводом промежуточной таблицы.

1. Зачем вам пятьсот однотипных таблиц словарей?
2. Вас что, двести пятьдесят промежуточных таблиц пугает ? Тогда вы внутрь SAPов/Peoplesoftов/JDEdvardсов лучше не смотрите, чтоб кондратий не хватил - там счет таблицам идет на тысячи. Причем, что характерно, работают на любой промышленной БД - Oracle, MS SQL, Informix, DB2, Sybase...