Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Пишу статью-обзор по используемым парадигмам отражения логических сущностей в приложениях на БД. Получилось пока что 3 парадигмы, кратко: 1) сущность -> строка в таблице 2) объектные схемы БД с "класс -> объект" архитектурой 3) объектные схемы БД с "прототип -> объект" архитектурой Может кто-нибудь в своей практике встечался с чем-то еще - более "экзотическим" и т.д.? Интересуют так же примеры схем БД и по этим 3 парадигмам(в основном по 2 и 3, т.к. в 1 досточно все просто). Заранее благодарю! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2005, 14:11 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Есть ещё одна парадигма - правильная. Это когда после составления схемы сущность-связь ещё идёт этап норализации. При этом отношение сущность - строка таблицы как правило нарушается. Почитали бы что ли книжки, чем кидаться писать статьи... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2005, 14:34 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Хмммм.... интересно, почему все себя априори считают уменее других? Начинают советовать почитать книжки и т.д.? У меня уже свыше 5 лет опыта проектирования БД и КИС систем, поэтому Ваш "наезд" просто считаю не актуальным. Согласен - есть некоторая небрежность в моем вопросе, но думается, что человек имевший дело с большими КИС понял бы меня. Позвольте расшифровать: Есть некоторая система в которой представлены некоторые логические сущности. Эти сущности должны как-то персистятся (сохраняться) в базу данных. Именно на этом этапе и "случаются" те парадигмы о которых я говорил. В самом простом случае сущность отражается таблицей (одной или несколькими), а колонки таблицы это аттрибуты сущности. В более сложных случаях в КИС обычно разрабатывают в БД свою собственную объектную модель - как бы "поверх" таблиц. Например возможна таблица object с полями object_id, name, parent_id, type_id ну и т.д. И уже разного типа сущности могут сохранятся в одну и туже схему таблиц. Ну и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2005, 15:01 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Илья(Phantom)...Эти сущности должны как-то персистятся (сохраняться) в базу данных.Wow... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2005, 15:11 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
> почему все себя априори считают уменее других? Действительно. Вы сами об этом что думаете? > У меня уже свыше 5 лет опыта проектирования БД и КИС систем Ну, пять лет можно штаны по-разному протирать. Авторством каких проектов Вы можете похвастать? > Есть некоторая система в которой представлены некоторые логические > сущности. Что это - "логические сущности"? Как они описаны? Работы каких авторов Вы хотите рассматривать в Вашей статье? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2005, 15:12 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Илья(Phantom)Хмммм.... интересно, почему все себя априори считают уменее других? Начинают советовать почитать книжки и т.д.? У меня уже свыше 5 лет опыта проектирования БД и КИС систем, поэтому Ваш "наезд" просто считаю не актуальным. Согласен - есть некоторая небрежность в моем вопросе, но думается, что человек имевший дело с большими КИС понял бы меня. Позвольте расшифровать: Есть некоторая система в которой представлены некоторые логические сущности. Эти сущности должны как-то персистятся (сохраняться) в базу данных. Именно на этом этапе и "случаются" те парадигмы о которых я говорил. В самом простом случае сущность отражается таблицей (одной или несколькими), а колонки таблицы это аттрибуты сущности. В более сложных случаях в КИС обычно разрабатывают в БД свою собственную объектную модель - как бы "поверх" таблиц. Например возможна таблица object с полями object_id, name, parent_id, type_id ну и т.д. И уже разного типа сущности могут сохранятся в одну и туже схему таблиц. Ну и т.д.Вам сюда и сюда . Welcome to the club ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2005, 15:51 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
да... смешно здесь у вас - ей Богу:) Вместо того, чтобы попробовать понять и помочь человеку пытаетесь воспринять все в штыки:) А я то думал - зарегюсь на сайте - мож что дельное скажут. 2 guest_20040621 Хотя бы IBM и Xerox что-нибудь говорят?:) Если угодно Логическая сущность = объект. Но это немного шире чем просто объект. В основном работы по онтологиям и экспертным системам В.Л.Стефанюка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2005, 15:58 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Илья(Phantom)да... смешно здесь у вас - ей Богу:) Вместо того, чтобы попробовать понять и помочь человеку пытаетесь воспринять все в штыки:) А я то думал - зарегюсь на сайте - мож что дельное скажут. 2 guest_20040621 Хотя бы IBM и Xerox что-нибудь говорят?:) Если угодно Логическая сущность = объект. Но это немного шире чем просто объект. В основном работы по онтологиям и экспертным системам В.Л.Стефанюка.Вы просто на мозоль наступили. Оцените размер топиков, на которые я тут ссылки дал (и восхититесь). Слова "персистить" выдают Вас с головой. Ничего более внятного, чем почитать правильные книжки посоветовать Вам не могу к сожалению. Есть только просьба - не пишите статью... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2005, 16:06 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
> Вместо того, чтобы попробовать понять и помочь человеку пытаетесь воспринять > все в штыки Дружище, меняйте стиль изложения. Не нужно чувствовать себя небожителем, сошедшим к простым смертным. Если Вам советуют что-то почитать прежде, чем писать статьи, то, скорее всего, не без основания. > Хотя бы IBM и Xerox что-нибудь говорят?:) Ну, есть такие лавки, и что? Интересно не Ваше место работы, а Ваши реальные проекты. Не знаю, как дела у Xerox, а криворукость т. н. девелоперов IBM мне известна. > Если угодно Логическая сущность = объект. Но это немного шире чем просто > объект. Понятно. Т. е. Вы попутно еще и неологизмы изобретаете. Imho напрасно, ну, да дело не в этом. Раз так, потрудитесь дать определение объекту и опишите разницу между "логическими" сущностями и объектами (заметьте, стоило Вам использовать формулировку "сущность логической модели", вопроса не возникло бы). > В основном работы по онтологиям и экспертным системам В.Л.Стефанюка. Не читал, хвастать не буду. Вопрос, однако, задам: по-Вашему, как онтология и экспертные системы связаны с предметом обсуждения? Насколько я знаю, никаких специальных методик проектирования они не предполагаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2005, 16:19 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Павел, поделитесь как слово "персистеть" может выдавать с головой? Здесь что-то кроется какой-то скрытый (чисто данного форума) смысл? Все проекты у нас делаются на J2EE и процесс сохранения (отражения) состояния системы в БД из покон веков назывался данным словом - сохранение. Что здесь может быть удивительного? Топики конечно потрясают - но не удивляют. Объектные БД не интересуют как таковые. Интересует процесс "трансформации" - логических сущностей из объектов одной системы в другую. Поймите, что материал уже набран, но вот проблема - термины абсолютно не те, к которым привыкли люди на этом форуме - те кто крутятся в основном в мире БД. Основная тема намного шире, а именно преобразования логических сущностей при изменении онтологии контейнера. То есть для представления одних и техе же знаний в разных системах могут использоваться разные системы "знаков и символов". Персистинг лишь один из примеров такого преобразования: когда в одной системе сущности представлены так-то, а при передаче ее в другую их надо трансформировать. Например в простом случае, что упоминал товарищ сверху одна сущность одной системы может "разбиваться" на несколько сущностей другой системы (несколько таблиц для хранения одной сущности). Ладно - я все понял. Товарищи на заграничных форумах намного теплее и понятливее, чем у нас. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2005, 16:38 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
> Объектные БД не интересуют как таковые. Да убогие они. Ограниченные. Без внятной теоретической базы. Исключительно для детерминированных задач. Что здесь в принципе может быть интересного? Болото. > материал уже набран, Публикуйте, в чем проблема? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2005, 16:49 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Интересуют конкретные пример схем БД для 2 и 3 типа перечисленных мной. Желательно "открытые", чтоб можно было сослаться и т.д. > Да убогие они. Ограниченные. Без внятной теоретической базы. Исключительно > для детерминированных задач. Что здесь в принципе может быть интересного? > Болото. даааа - болото болотом и нафига мы его разрабатываем....:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2005, 17:05 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Автору искренне КГ/АМ. Пересказывать то, о чем здесь годами тщательно и в подробностях претирают, народ, видимо, не хочет. А что, в лом поискать "маппинг|mapping" по конфам? Или "термин термин абсолютно не тот" ... в смысле - не знакомый? Ну так и отношение соответствующее. А поискать, так статья может показаться не очень нужной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2005, 17:11 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
> Интересуют конкретные пример схем БД для 2 и 3 типа перечисленных мной. Это предложение работы? Хм... лично мне эта задача не интересна. Поскольку а) тривиальна, б) уже имеет решения. > даааа - болото болотом и нафига мы его разрабатываем....:) Предположу: бабло зарабатываете. Что само по себе не предосудительно: кушать всем хочется. Только делаете Вы это хм... не слишком профессионально. ;)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2005, 17:22 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Илья(Phantom) Поймите, что материал уже набран, но вот проблема - термины абсолютно не те, к которым привыкли люди на этом форуме - те кто крутятся в основном в мире БД. Основная тема намного шире, а именно преобразования логических сущностей при изменении онтологии контейнера. То есть для представления одних и техе же знаний в разных системах могут использоваться разные системы "знаков и символов". Персистинг лишь один из примеров такого преобразования: когда в одной системе сущности представлены так-то, а при передаче ее в другую их надо трансформировать. Например в простом случае, что упоминал товарищ сверху одна сущность одной системы может "разбиваться" на несколько сущностей другой системы (несколько таблиц для хранения одной сущности). Если Вы и статью в таком стиле и такой терминологии собираетесь публиковать, кто её поймёт??? --- "Raffiniert ist der Herr Gott, aber boshaft ist Er nicht." Albert Einstein ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2005, 17:32 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Илья(Phantom)Пишу статью-обзор по используемым парадигмам отражения логических сущностей в приложениях на БД. Получилось пока что 3 парадигмы, кратко: 1) сущность -> строка в таблице 2) объектные схемы БД с "класс -> объект" архитектурой 3) объектные схемы БД с "прототип -> объект" архитектурой Может кто-нибудь в своей практике встечался с чем-то еще - более "экзотическим" и т.д.? Интересуют так же примеры схем БД и по этим 3 парадигмам(в основном по 2 и 3, т.к. в 1 досточно все просто). Заранее благодарю! -- Multidimensional ("star" / "snowflacke" схемы) ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2005, 18:01 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Илья(Phantom)Пишу статью-обзор по используемым парадигмам отражения логических сущностей в приложениях на БД. Получилось пока что 3 парадигмы, кратко: 1) сущность -> строка в таблице ... А где собственно реляционный подход? То, что вы привели в п. 1 есть только частный случай. В более общем случае, каждый кортеж отношения представляет вовсе не сущность, а некоторый факт, то есть истинностное утверждение (аксиому), соответствующее предикату отношения. При этом информация о некоторой сущности реального мира представляется только всей совокупностью фактов о ней, хранящихся в БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 08:18 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
И еще. Как же можно писать о БД и жаловаться, что "вот проблема - термины абсолютно не те, к которым привыкли люди на этом форуме - те кто крутятся в основном в мире БД." Это выше моего понимания. Это, скажем, как писать специализированную статью о биологии и сетовать та то, что приходится использовать термины, привычные биологам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 08:23 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Как я понимаю автор просто пишет диссертацию и ему нужен список литературы )....Но мне не совсем понятно, что он хочет? Он хочет найти методики "объектно-ориентированного преобразования?"....Тогда нужно смотреть работы Ambler'а....Там есть примеры. А конкретная реализация так это Bold для Дельфи. Там можно построить БД в понятиях классов, а сохранить в реляционной БД (либо в XML). Я смотрел отображение на InterBase. И подобных инструментов куча. Мне кажется автор не до конца описал задачу исследования :)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 10:12 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Jimmy-- Multidimensional ("star" / "snowflacke" схемы) ? Образцовый пример первого типа из перечисленных. Потому как именно что в отличие от нормализованных схем сущность почти однозначно соответствует строке в таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 10:45 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
А почему "звезда" описывает одну сущность в строке таблицы фактов? Ведь там же множество внешних ключей на размерности? И получается что одна строка содержит только ничего не значащие значения (внеш. ключи). А сами данные требуется получать из других таблиц. Так или я что-то не попимаю? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 10:49 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Int23А почему "звезда" описывает одну сущность в строке таблицы фактов? И в строке таблицы измерений тоже. Единственно, принцип несколько нарушается с иерархиями в строгой звезде. Int23Ведь там же множество внешних ключей на размерности? И чему это противоречит? Допустим, я живу возле м. Сокол. Это - атрибут меня как сущности. Но само м. Сокол вместе со всеми его рельсами, поездами, сотрудниками, Ленинградским шоссе над и домами вокруг - моим атрибутом не является. Так и здесь: атрибутом, реквизитом факта является "упоминание", ссылка на измерение, "измерение как объект", но не атрибуты собственно измерения. Int23И получается что одна строка содержит только ничего не значащие значения (внеш. ключи). А сами данные требуется получать из других таблиц. Так или я что-то не попимаю? Полагаю, Вы глобально заблуждаетесь. В первую очередь, строка таблицы содержит не столько внешние ключи, сколько значения, measures. Скажем, для факта покупки - сумму покупки. Таблицы фактов, все атрибуты которых являются измерениями - вырожденный случай; я такого, пожалуй, никогда не встречал. Можно, конечно, сделать сумму покупки измерением - но смысл? Во вторую очередь, Вы путаете форму и содержание. Вы путаете постулат "значение суррогатного ключа не несет смысловой нагрузки, не имеет физического смысла" - со смыслом наличия этого ключа в таблице фактов. Внешний ключ в таблице фактов не нужен для доступа к данным измерения. Если есть измерение, допустим, (код района, название района) - второе из этих полей нужно исключительно для целей визуализации. Никакой информации для обработки оно не несет. Если Вы захотите узнать, например, "десять районов с наибольшим объемом продаж" - Вы сделаете запрос к таблице фактов (продаж), найдете эти десять районов, а затем, может быть, для визуализации загляните в справочник и возьмете их названия. Разумеется, в измерениях в принципе могут храниться какие-то показатели. Скажем, может храниться ставка НсП, разная для разных субъектов федерации. Но во-первых, именно этот случай - скорее исключение, а во-вторых, это будет именно атрибут субъекта федерации, измерения (меняющийся по времени). Атрибутом продажи может быть "текущая ставка НсП" - которая как правило будет выделена как measure в таблице фактов, скорее даже как "В том числе НсП". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 11:06 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
[quot softwarer Образцовый пример первого типа из перечисленных. Потому как именно что в отличие от нормализованных схем сущность почти однозначно соответствует строке в таблице.[/quot] Ну, насчет образцовости я бы не стал утверждать, т.к. кроме иерархий (в "звезде") есть и другие отличия, типа истории изменения значения атрибута, которая хранится в таблице фактов. Если учитывать это обстоятельство, то понятие "сущность -> строка в таблице" нужно расширить до "сущность в определенный момент времени -> строка в таблице" Мне так кажется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 11:21 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Попробуем перевести обсуждение в более техническую плоскость. Есть два факта: "Джим съел собаку", "Вчера Джим получил письмо от Джейн" Логически (не вдаваясь в вопросы о ключах и индексах) их можно формализовать различными предикатными конструкциями: Код: plaintext Код: plaintext 1. Код: plaintext 1. 2. 3. Способы отличаются тем, что в одном случае "съел" отображается в атрибут, в другом в предикат, в третьем в значение. 2 Илья(Phantom) : не вдаваясь в вопрос о том какое их этих отображений правильное (в частности что будет если Джим съест еще кого-нибудь или получит больше писем :), только чтобы понять вашу терминоглогию, точнее, ее применение к БД: сколько здесь парадигм? сколько здесь онтологий? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 12:17 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
JimmyНу, насчет образцовости я бы не стал утверждать, Скажем так, куда более близкий к образцу, нежели обычная нормализованная схема :) Jimmy есть и другие отличия, типа истории изменения значения атрибута, которая хранится в таблице фактов. Тут, пожалуй, околотерминологическое расхождение. Сущностью в MDM-cхеме в общем случае является "факт", именно что одна строка в таблице. В ранее упомянутом кубе покупок - факт покупки, то, что Вы назвали "сущностью в определенный момент времени". Время - или другой "исторический" разрез - является одним из измерений этого куба. С тем же успехом можно рассматривать не временной аспект, а например географический - сущность вроде бы одна, но продаж по Москве больше, чем по Питеру. Разумеется, с логической точки зрения можно сказать, что таким срезом куба описывается некая "сущность реального мира". Но здесь с моей точки зрения как раз один из тех случаев, когда в проектировании уходят от однозначного соответствия реальных объектов сущностям проекта. Да, в реальном мире есть такая сущность. А в нашем проекте мы мыслим несколько другими. У этих других может быть прямой аналог в реальном мире - как у продаж, а может и не быть. Разумеется, в любой практической схеме будут исключения. Например, факт "замена" может быть выражен не только строкой в таблице "замен", но также строками в таблицах "покупка" - "возврат" - "покупка", если это отчего-то удобнее. История как контрпример принципа "одна строка - одна сущность" опять-таки видна скорее в таблицах измерений, во всяких SCD2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 12:34 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
ModelR сколько здесь парадигм? сколько здесь онтологий? сколько здесь болтологий??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 12:48 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
И естественно, мы неизбежно приходим к вопросу о том, что такое "сущность". И тут можно встретить 2 точки зрения: 1. Бизнес-сущность. Что-то, существующее в предметной области, вполне различимое, известное и понятное специалистам/пользователям. 2. Сущность-факт. Что-то, о чем можно сделать запись в данной таблице БД. В этой теме можно наблюдать обе точки зрения. При этом использование одного и того же термина "сущность" приводит стороны к недопониманию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 12:56 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
2 mir Не подскажете [толковый] словарь стандарной терминологии (относительно БД), который не вызывал бы кривотолков? А то, блин, часто доводится видеть различные пояснения одних терминов и (почти) идентичные пояснения различных терминов :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 13:10 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Насчет словаря. ИМХО лучше, чем это у нас не найти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 13:45 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
mirИ естественно, мы неизбежно приходим к вопросу о том, что такое "сущность". И тут можно встретить 2 точки зрения: 1. Бизнес-сущность. Что-то, существующее в предметной области, вполне различимое, известное и понятное специалистам/пользователям. 2. Сущность-факт. Что-то, о чем можно сделать запись в данной таблице БД. В этой теме можно наблюдать обе точки зрения. При этом использование одного и того же термина "сущность" приводит стороны к недопониманию. Использование термина сущность для обозначения строки в таблице конечно неудачно. Сущность-факт, событие, сущность-связь других сущностей, как и сущность предмет - частные случаи сущности. Все они понятны бизнесу, только каждому по-своему . Вот дождь -это процесс или предмет? Нет, нет, не отвечайте плз., это не вопрос а иллюстрация. XM 2 mir Не подскажете [толковый] словарь стандарной терминологии (относительно БД), который не вызывал бы кривотолков? А то, блин, часто доводится видеть различные пояснения одних терминов и (почти) идентичные пояснения различных терминов :( Лучше Дейта никто объяснять не умеет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 14:00 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
softwarer Jimmy есть и другие отличия, типа истории изменения значения атрибута, которая хранится в таблице фактов. Тут, пожалуй, околотерминологическое расхождение. Сущностью в MDM-cхеме в общем случае является "факт", именно что одна строка в таблице. В ранее упомянутом кубе покупок - факт покупки, то, что Вы назвали "сущностью в определенный момент времени". Время - или другой "исторический" разрез - является одним из измерений этого куба. С тем же успехом можно рассматривать не временной аспект, а например географический - сущность вроде бы одна, но продаж по Москве больше, чем по Питеру. Разумеется, с логической точки зрения можно сказать, что таким срезом куба описывается некая "сущность реального мира". Но здесь с моей точки зрения как раз один из тех случаев, когда в проектировании уходят от однозначного соответствия реальных объектов сущностям проекта. Да, в реальном мире есть такая сущность. А в нашем проекте мы мыслим несколько другими. У этих других может быть прямой аналог в реальном мире - как у продаж, а может и не быть. Разумеется, в любой практической схеме будут исключения. Например, факт "замена" может быть выражен не только строкой в таблице "замен", но также строками в таблицах "покупка" - "возврат" - "покупка", если это отчего-то удобнее. История как контрпример принципа "одна строка - одна сущность" опять-таки видна скорее в таблицах измерений, во всяких SCD2. Закроем глаза на "куб" и вообще любую многомерную структуру, кроме реляционной модели. Возьмем упрощенную модель: Сущность "Лицевой Счет" -- Номер счета - атр. -- Наименование счета - атр. -- Остаток на счете - атр. /* Существенная характеристика,изменяется во времени, т.е существует серия значений: --- (на 01.01.2005) --- (на 02.01.2005) --- (на 03.01.2005) --- (на 04.01.2005) --- (на 05.01.2005) --- (на 06.01.2005) ::: */ -- Дата открытия - атр. -- Дата закрытия - атр. Таблицы: - Account -- Account number (PK) -- Account name -- Open date -- Close date - Balance -- Account number(PK)(FK Account) -- Actual date(PK) -- Account balance Таким образом, "сущность - строка" описывается следующим запросом: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. т.е. именно "сущность в определенный момент времени - строка". Иначе - "сущность - много строк". ЗЫ Хотя, как я понимаю, все дело в интерпретации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 14:54 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
ModelRИспользование термина сущность для обозначения строки в таблице конечно неудачно.Я тоже так считаю. ModelRСущность-факт, событие, сущность-связь других сущностей, как и сущность предмет - частные случаи сущности.Точнее даже так: иногда запись в таблице соответствует бизнес-сущности (часный случай), но в общем случае информация о бизнес-сущности отображается на несколько записей в нескольких таблицах. Речь, разумеется, идет о РМД. ModelRВсе они понятны бизнесу, только каждому по-своему.Полагаю, что "бизнесу" (т.е. пользователям) понятны исключительно бизнес-сущности, которые ему видны на внешнем уровне представления (по ANSI/SPARC). Всякие же "таблицы", "записи" и т.п. относятся к логическому уровню, который "бизнес" не видит и о котором часто даже не подозревает.[/quot] ModelRВот дождь -это процесс или предмет? Нет, нет, не отвечайте плз., это не вопрос а иллюстрация.Мысль я не уловил, сорри. XM 2 mir Не подскажете [толковый] словарь стандарной терминологии (относительно БД), который не вызывал бы кривотолков? А то, блин, часто доводится видеть различные пояснения одних терминов и (почти) идентичные пояснения различных терминов :(Сам бы такой хотел :) Собираешь всю жизнь с миру по нитке. Хороший источник "вразумления" - сайт Дейта и Паскаля http://www.dbdebunk.com. Но там все не систематизировано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 15:07 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Jimmy Закроем глаза на "куб" и вообще любую многомерную структуру, кроме реляционной модели. Возьмем упрощенную модель: Сущность "Лицевой Счет" -- Номер счета - атр. -- Наименование счета - атр. -- Остаток на счете - атр. /* Существенная характеристика,изменяется во времени, т.е существует серия значений: --- (на 01.01.2005) --- (на 02.01.2005) --- (на 03.01.2005) --- (на 04.01.2005) --- (на 05.01.2005) --- (на 06.01.2005) ::: */ -- Дата открытия - атр. -- Дата закрытия - атр. Таблицы: - Account -- Account number (PK) -- Account name -- Open date -- Close date - Balance -- Account number(PK)(FK Account) -- Actual date(PK) -- Account balance Таким образом, "сущность - строка" описывается следующим запросом: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. т.е. именно "сущность в определенный момент времени - строка". Иначе - "сущность - много строк". ЗЫ Хотя, как я понимаю, все дело в интерпретации.В чем прикол? Таблиц ведь у вас две не случайно: логически сущностей тоже две Счет(Номер,Наименование,ДатаОткрытия,ДатаЗакрытия) и ОстатокСчета(Номер,Дата,Сумма) и связь Каждый Счет имеет несколько ОстатокСчета. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 15:15 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Вот это и есть та самая интерпретация, о которой я говорил. Логически - как раз-таки одна сущность. Выделение сущности "остаток на счете" с точки зрения проектировщика оправдано, конечно, но с точки зрения бизнеса - несколько натянуто. Тест простой: -- Существует счет без остатка? -- Существует ли остаток без счета? Т.е. налицо композиция (в терминах ООП) ЗЫ Чтобы понятия развести: -- есть связи (1-М, М-М), которые применимы к парам " естественная сущность (объект реального мира) - естественная сущность (объект реального мира)", т.е. воспроизводят парадигму, по словам автора треда, "сущность-запись" -- есть связи (1-М, М-М), которые применимы к парам " естественная сущность (объект реального мира) - суррогатная сущность (суррогатный объект, созданый для хранения атрибутов естественной сущности), т.е. то, что чаще всего и характерно для МДМ схем. Несмотря на внешнюю схожесть это - разные вещи, что и сбивает с толку, наверное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 16:32 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Извините, поправка: -- есть связи (1-М), которые применимы к парам " естественная сущность (объект реального мира) - суррогатная сущность (суррогатный объект, созданый для хранения атрибутов естественной сущности), т.е. то, что чаще всего и характерно для МДМ схем ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 16:36 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
JimmyЛогически - как раз-таки одна сущность. Выделение сущности "остаток на счете" с точки зрения проектировщика оправдано, конечно, но с точки зрения бизнеса - несколько натянуто. Я и говорю - вопрос в терминологии. Соотношение "одна бизнес-сущность - одна строка в таблице" - имеет максимальные шансы быть нарушенным, с этим трудно спорить, да и незачем. Если мы помним, что физическая и логическая модели не обязаны соответствовать одна другой - конфликта не остается. У нас есть логическая модель с бизнес-сущностями, у нас есть физическая модель с таблицами (которые, если не ошибаюсь, Кодд и называл сущностями). В логической модели - если нам удобно так думать, давайте нарисуем счет с таблицей остатков. В Oracle Designer, кстати, для этого было очень удобное средство: можно было вкладывать сущности одна в другую. А потом появились nested tables, что дает "один в один" воспроизвести это отношение на физическом уровне. Обсуждать, насколько далеко это от изначального утверждения автора - имхо бессмысленно. Ограничусь утверждением, что для "кубических" задач фактом будет именно "остаток по счету.. на дату.. равен..". Не потому что мы его натянуто выделили, а объективно - по смыслу решаемых задач. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 17:08 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
2 softwarer Я согласен с каждым Вашим словом :0)) Просто, видимо формулировать парадигмы нужно было несколько иначе,в контексте решаемых задач, т.е: -- БД для регистрации транзакций (OLTP системы, 3-4 НФ) -- БД для получения отчетов (OLAP в том числе, "звезда", "снежинка") -- БД - универсальное "хранилище" ("объектная" надстройка над РСУБД) 2 Илья(Phantom) Мне кажется, что такая классификация более соответствует практическим целям, нежели предложенная Вами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 17:17 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Лучше бы Вы, Jimmy, для начала, закрыли глаза на реляционную модель... В Вашем примере можно увидеть две "естественные", как Вы выразились, сущности - Счет и День. И связь между ними Счет - Имеет остаток на/За который имеется остаток по - День с характеристикой связи "Остаток". И ничего здесь не натянуто даже с точки зрения бизнеса... Павел Воронцов: "... при этом отношение сущность - строка таблицы как правило нарушается". Не нарушается это "отношение" в результате нормализации (сущность - это все, что может быть идентифицировано, а кортеж, хотя и не эффективно, но может быть "идентифицирован", и можно "безнаказанно" утверждать, что он представляет некоторую, возможно не выявленную в начале на концептуальном уровне, сущность). Может быть речь идет о представлении в РМД связей М:М ? В этом случае соответствующее отношение представляет связь между сущностями. Либо сущность, либо связь между сущностями. Вы, Илья, про связи "забыли" в п.1... "Парадигмы отражения", видимо, следует различать по механизмам идентификации сущностей, механизмам представления связей между сущностями и возможностям прямого доступа к сущностям (которого может не быть, например, если "сущность" "встроена" в другую "сущность")... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 18:50 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
JimmyЛогически - как раз-таки одна сущность. Выделение сущности "остаток на счете" с точки зрения проектировщика оправдано, конечно, но с точки зрения бизнеса - несколько натянуто. Не согласен. Каковы бизнес правила в данном случае? (1) Каждый счет имеет единственное Наименование (2) Каждый счет имеет один или несколько Остатков. как иначе их выразить не вводя понятие Остаток? Я не говорю, что этот язык абсолютно понятен бизнесу, однако это то минимальное общее понятийное поле, на котором проектировщик может надеятся найти общий язык с бизнесом на этапе проекта. softwarer Если мы помним, что физическая и логическая модели не обязаны соответствовать одна другой - конфликта не остается. У нас есть логическая модель с бизнес-сущностями, у нас есть физическая модель с таблицами (которые, если не ошибаюсь, Кодд и называл сущностями). В логической модели - если нам удобно так думать, давайте нарисуем счет с таблицей остатков. В Oracle Designer, кстати, для этого было очень удобное средство: можно было вкладывать сущности одна в другую. А потом появились nested tables, что дает "один в один" воспроизвести это отношение на физическом уровне. Уточнение. В Oracle Designer вложение А в Б означало "Каждое А есть Б" в смысле состава атрибутов, т.е. скорее это было наследование. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 21:55 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Илья(Phantom) Пишу статью-обзор по используемым парадигмам отражения логических сущностей в приложениях на БД. Все-таки разнообразие взглядов и терминов на приложения БД все еще спосбно впечатлять. Термин парадигма прижился в технология программирования, но еще, вроде, не пробил себе дорогу в приложениях БД. Под логическими сущностями, наверное, понимаются средства структурирования данных и противопоставляются не логическим - сущностям реалного мира. И они типа разные у разных моделей данных. И их надо отображать как это происходит при трансляции модели данных ER в РМД. Тада может лучше спользовать терми "Категория"? В том смысле, что каждой модели свои категории. В, конце концов, в математике есть теория категорий, которая занимается как раз отображениями. Я не призываю ее использовать, а говорю о смозвучности. Кроме того, термин онтология заимствован, наверное, из философии, и возможно, категория там с онтологией хорошо, уживаются. Но в любом случае есть модели, которые использут термин сущность и есть которые не используют. И не известно существует этот термин, только благодаря некотром моделям данных, или его природа выходит за рамки этих моделей. Илья(Phantom) Если угодно Логическая сущность = объект. Но это немного шире чем просто объект. Объекты тоже используют и в смысле обектов реального мира, и в смысле средств структурирования данных. Т.е. тада вторые тоже могут быть логическими? Сложность в том, что уже используются термины концептуальные и физические в одном ряду с логическими. И как правило, например, концептуальные отображаются в логические, а последние в физические. Реже наоборот и на одном уровне. Хотя считается некоторыми авторами, что иерархические можно отобразить в реляционные. Я намекаю, на то что прилогательное "логические", возможно лучше выкинуть, а за одно и термины "парадигму" и "онтология" тоже претендуют на удаление из статьи про приложения БД. Ну возможно, что объект в ООП уже сущности в ER, потому что строго идентифицирован и имеет дополнительные возможности - поведение. Т.е. больше признаков как у понятия. Илья(Phantom) В основном работы по онтологиям и экспертным системам В.Л.Стефанюка. Зкспертные системы все же предполагают не приложения БД, а приложения БЗ (Баз знаний). Там, скорее всего, все сложнее и тока сущностиями, хотя и логическими, не отделаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 22:10 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
vadiminfoЯ намекаю, на то что прилогательное "логические", возможно лучше выкинуть, а за одно и термины "парадигму" и "онтология" тоже претендуют на удаление из статьи про приложения БД.А чем же тогда поразить вероятного читателя статьи ? Дабы увидев эти слова, просветлился и понял, что не лох какой писал, а человек ученый... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2005, 01:10 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Ну, с термином "парадигма" не все так плохо. Это просто *концепция*, *модель постановки проблем и их решения*. Термин часто применяется для большего наукообразия. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2005, 06:36 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
2 Андрей Леонидович Лучше бы Вы, Jimmy, для начала, закрыли глаза на реляционную модель... В Вашем примере можно увидеть две "естественные", как Вы выразились, сущности - Счет и День. И связь между ними Счет - Имеет остаток на/За который имеется остаток по - День с характеристикой связи "Остаток". И ничего здесь не натянуто даже с точки зрения бизнеса... 0. Насчет закрытия глаз на реляционную модель - не понял, извините. 1. Рекомендую взглянуть, к примеру, на документ/форму/отчет "Выписка по счету", "Баланс" и т.п. Любой из этих документов, столь любимых бухгалтерами - срез состояния счета/ов на определенную дату. 3. И, еще раз повторюсь, специально для Вас: "Хотя, как я понимаю, все дело в интерпретации" (с) Jimmy. Т.е. можно привести массу аргументов в пользу любой модели, и все они будут достаточно разумными (равно как и массу контрагрументов). 4. Тем не менее, смею утверждать, что нельзя смешивать концепции проектирования OLTP систем и DSS систем, т.к. они решают разные задачи, и вот контекст этих задач имеет смысл назвать "парадигмой" или как-то еще. Ни больше - ни меньше. 5. Исходя из п.3 думаю флейм нужно прекратить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2005, 10:18 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
ModelRУточнение. В Oracle Designer вложение А в Б означало "Каждое А есть Б" в смысле состава атрибутов, т.е. скорее это было наследование. Хм. Боюсь, я лет шесть им не пользовался; за это время что-то могло поменяться, да и я могу ошибиться. Что есть "означало"? Насколько я помню, я применял это для "технических детальных таблиц", например - мог вложить в клиента таблицу "телефонные номера клиента", привязанную к клиенту по FK, многие к одному, и не имеющую других ссылок. По этой ER-ке генерилась нормальная (ожидаемая мной) структура таблиц. Наследованием такое вроде бы не является :) Хотя не исключаю, что я по неведению использовал фичу не так, как предполагали разработчики. Но было весьма удобно :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2005, 10:56 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Уважаемый Jimmy ! 0. "Закроем глаза на "куб" и вообще любую многомерную структуру, кроме реляционной модели." Вот откуда взялось "закрытие глаз". 1. Ну зачем же "сопоставлять" представление сущностей в БД и представление отчетов пользователям ? Хотя в идеале, конечно, эти представления могли бы совпадать. 3. Все дело, скорее, в сути, а не в интерпретации. 4. Существуют прикладные системы, в которых OLTP и DSS работают на одной БД. Можно, и даже нужно, "смешивать концепции". 5. Исходя из п.3 флейм может и нужно прекратить, но не путь к истине. Наверное ?.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2005, 13:03 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Закроем глаза на "куб" и вообще любую многомерную структуру, кроме реляционной модели." Вот откуда взялось "закрытие глаз". Весьма странный вывод. Структура куба (MOLAP) - вещь далекая от РСУБД. И рассуждать о его устройстве - дело неблагодарное, в рамках данной темы, во всяком случае. Или, я просто не уловил Вашу логику? Существуют прикладные системы, в которых OLTP и DSS работают на одной БД. Можно, и даже нужно, "смешивать концепции ОК, по простому скажу: 1. "Звезду" можно свести к одной таблице (сущности?), денормализованной до 1НФ, при этом DSS система будет работать . Т.е. процессы получения необходимых отчетов и/или формирования куба не пострадают, а может даже ускоряться. 2. OLTP схему, в принципе, тоже можно свести к одной мега-таблице (сущности?). При этом... будет "абзац" системе. Свою функцию она выполнять не сможет . Это, по вашему, одна и таже концепция (или парадигма?) проектирования? Что-ж, не буду разубеждать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2005, 13:18 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
1. Да, Вы не уловили мою логику. Вы предложили закрыть глаза на одно, а я Вам - на другое. Это была ирония, конечно - не нужно ни на что закрывать глаза... 2. Если проектируемая БД предназначена для решения и тех, и других задач, то те "концепции проектирования", о которых Вы говорили, конечно "смешиваются". При чем здесь "сведение к одной таблице" ??? У Вас должна быть хорошо нормализованная, и, одновременно, хорошо денормализованная ОДНА БД... Поскольку автор темы ей уже не интересуется, и не захотел четче сформулировать "проблему" (обиделся, вроде как, непонятно на что), то и обсуждать нечего... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2005, 17:56 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
> обсуждать нечего... Отчего же? Очень даже есть чего. Что абсолютно непонятно: на каком основании некоторые из участвующих в обсуждении взяли один класс задач и ограничили концепции проектирования применительно исключительно к этим задачам. На мой взгляд, частные случаи никогда ничего не доказывали. Imho member ModelR в [1550920] был к ответу на исходный вопрос ближе всего. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2005, 18:17 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Нет, guest_20040621. ModelR тоже предложил (ДВАЖДЫ в упомянутом Вами сообщении !) "не вдаваться в вопросы" (чем это отличается от "закрывать глаза" ?). Он может быть образнее других указал автору на не четкую формулировку "проблемы". Это да... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2005, 18:54 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Илья(Phantom), если Вы еще "здесь". Конкретные примеры схем БД для 2 и 3 на логическом уровне ничем не отличаются от аналогичных схем для 1. Надеюсь "товарищи на заграничных форумах" Вам уже объяснили, что: 1) в ООСУБД связи многие-ко-многим на логическом уровне представляются так же, как и в "Р"СУБД; 2) встраивание объектов осложняет (мягко говоря) доступ к встроенным объектам (сущностям), и, опять же, реализовано и в большинстве "Р"СУБД (то бишь теперь - О"Р"СУБД)... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2005, 19:15 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Все, капец топику. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2005, 05:46 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
c127Все, капец топику.Весеннее обострение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2005, 06:25 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
2 Павел Воронцов Я тут подумал, что Андрей Леонидович приобрел репутацию паленой водки: сначала столбенеешь, потом становится весело, но в итоге сильно тошнит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2005, 07:02 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
mir2 Павел Воронцов Я тут подумал, что Андрей Леонидович приобрел репутацию паленой водки: сначала столбенеешь, потом становится весело, но в итоге сильно тошнит.Да, похоже. Вообще тут уже легенды об Андрее Леонидовиче ходят (как о местном Гайавате). Скольких участников форума он сподвиг на обширные цитаты из классиков! И каке цитаты, мммм! За что ему большое человеческое спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2005, 07:29 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
А может быть он уже сваял ПАРУ ФОРМУЛ ? Андрей Леонидович, ВЫКЛАДЫВАЙТЕ!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2005, 11:02 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Откуда такая бурная реакция ? Вроде человек говорит по делу, аргументирует и к своим предыдущим сообщениям не отсылает. Некрасиво поступаете ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2005, 14:15 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
xОткуда такая бурная реакция ? Вроде человек говорит по делу, аргументирует и к своим предыдущим сообщениям не отсылает. Некрасиво поступаетеБог в помощь! Общайтесь. А я в сторонке постою пока. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2005, 14:20 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Павел Воронцов Ну хоть бы раз постояли :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2005, 14:28 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
funikovyuri :-) Постараюсь исправиться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2005, 14:52 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Ну наконец-то наши любимые настоящие профессионалы начали высказываться по существу темы. Но, похоже, поздно. Никого она уже не интересует... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2005, 23:00 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
x Откуда такая бурная реакция ? Вроде человек говорит по делу, аргументирует и к своим предыдущим сообщениям не отсылает. Некрасиво поступаете Существуют некоторые, возможно, неписанные правила, как минимум в технических дискуссиях, нарушение которых предполагает подозрения в грубой пропаганде уличного типа. В митинговщине. Тем более их многократное и злостное нарушение. Тем более явный перебор. Кроме того, имеет значение чувство меры. Такие перлы как "беда с ключами" или "крах реляционной модели" в сочетании с плохо скрываемым желанием протащить на первые позиции какую-то непонятную не то СУБД, не то перманентный язык, с дореляционной объектной моделью данных (как Вам нравится названьице?), да еще функционирующей на платформе другой СУБД (Кеша) в сочетании с мумпосом делают свое дело. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2005, 15:58 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
2 x >Откуда такая бурная реакция ? Это продолжение старого разговора, почитайте если вдруг не в курсе. Разговор длинный, начало разговора тут, если не ошибаюсь: /topic/9021&pg=14 Как видно поначалу к известному персонажу отнеслись нормально несмотря на явную агрессивность оного. Павел Воронцов mir2 Павел Воронцов Я тут подумал, что Андрей Леонидович приобрел репутацию паленой водки: сначала столбенеешь, потом становится весело, но в итоге сильно тошнит.Да, похоже. Вообще тут уже легенды об Андрее Леонидовиче ходят (как о местном Гайавате). Скольких участников форума он сподвиг на обширные цитаты из классиков! И каке цитаты, мммм! За что ему большое человеческое спасибо. Лучшая цитата ИМХО эта: Alex.CzechСтарик Державин нас заметил и в гроб сходя благословил /topic/9021&pg=52 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2005, 01:14 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Сильно, все-таки, задело vadiminfo замечание его коллеги о том, что он, как и другие мои оппоненты, ведет дискуссию не корректно. Не стоит обижаться, мне кажется, и раздражаться из-за того, что знания в области РМД (а вовсе не каких-то других "экзотических" моделей данных) оказались, скажем так, не достаточными, и это, конечно, серьезно мешает моим оппонентам понимать и другие модели данных. А ведь я от своего предложения не отказывался. Вы ведь из Обнинска, vadiminfo ? Я даже к вам готов приехать на семинар по "КЛЮЧАМ В РМД и ИДЕНТИФИКАТОРАМ В ОМД" (раз выяснилось, что еще рано сравнивать модели данных и "парадигмы отображения сущностей" в БД). Ну совсем уж узкая тема, и вроде бы всем хорошо известная. Я сделаю доклад (30 мин). Вы и Ваши коллеги зададут все вопросы, я на них отвечу (60 мин). Потом Вы сделаете доклад (30 мин), и ответите на мои вопросы (60 мин.). Подготовим согласованный отчет, и опубликуем его... И, еще раз напоминаю, я здесь ничего не собирался и не собираюсь "протаскивать" и "навязывать". Я только сообщал о том, о чем другие участники дискуссии не знают, как мне казалось. И ход дискуссии в двух темах, в которых я участвовал, показал, что мои предположения оказались верными. Действительно не знают. А вот то, что и знать не хотят, оказалось для меня неожиданностью... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2005, 17:58 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Андрей Леонидович знания в области РМД (а вовсе не каких-то других "экзотических" моделей данных) оказались, скажем так, не достаточными, и это, конечно, серьезно мешает моим оппонентам понимать и другие модели данных. Про то у кого какие знания Вам видней. Я не препад, и оценивать знания других не собираюсь. Что касается моделей данных, то дореляционная объектная, которая получается выкидыванием из ООМД собственно ООП и потому не "экзотическая", а "обрезанная". Причем здесь термин дореляционная имеет значение - речь идет о Вами представлячемой какой-то не то модели не еще чего-то, что Вы так назвали. Есть Объектно семантические и проч. И в общем случае ER относят у объетным. Но они не имеют отношения к Вашей ДоРОМД. Андрей Леонидович А ведь я от своего предложения не отказывался. Вы ведь из Обнинска, vadiminfo ? Я даже к вам готов приехать на семинар по "КЛЮЧАМ В РМД и ИДЕНТИФИКАТОРАМ В ОМД" (раз выяснилось, что еще рано сравнивать модели данных и "парадигмы отображения сущностей" в БД). Вы что думаете, что у Вас есть что-то новое по сравнением с тем, что Вы здесь сказали? Вы про ключи прочитали какие-то введения для начинающих или обрывки из середены, вырванные из контекста. Думаете, в этом есть польза, чтобы про это слушать? Полно нормальной литры - где все систематически изложено. Зачем мне какие-то сомнительные лекции? Что в ООМД не смотря на OID все еще нужны ключи - Вы не поняли. Не согласились и не привели технических доводов (не технические приводили, но они ничего, к сожалению, не стоят). Я привел, Вы не опровергли. Здесь на форуме. Вместо этого применяли приемы не имеющие к доказательствам тех вещей никакого отношения. Например, одурачить, заговорить зубы начальству - возможно для этого такие приемы годятся. Но здесь начальства нет, поэтому они не проходят. Андрей Леонидович Сильно, все-таки, задело vadiminfo замечание его коллеги о том, что он, как и другие мои оппоненты, ведет дискуссию не корректно. Не стоит обижаться, мне кажется, и раздражаться из-за того, что знания в области РМД Образец не технического приема. Я, к примеру, не думал обижаться - нет знаний так нет. Но теперь дело представлено так, что Ваши доводы чего-то стоили. Но доказывать их не надо, потому что кто с ними не согласится у того нет знаний, и он обижается. Эти фарисейские приемы не дают пользы для решения технических вопросов. И пока не появятся сведения об оратном, лучше считать, что им место где-нибудь на маевке, а не форуме и тем более семинаре. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2005, 21:40 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Ну вот. Опять съехали на обсуждение у кого провалы в образовании глубже и ширше, аргументы пропали, опять пошли ссылки на старые топики... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2005, 10:31 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Мимо пробегал настоящий боец. А какой дизайн сообщений ! Невозможно пробежать мимо... Мимо пробегал ! Нам с Вами не нужно "ваять" никаких формул. Они "сваяны" более 30-ти (а, скорее, более 120-ти) лет назад. Вам нужно только понять, что дореляционная ОМД (понимаю, что прилагательное "дореляционная" бьет по самолюбию некоторых знатоков теории баз данных, но факты - упрямая вещь) включает и концептуальную модель окружающего мира (то есть это в первую очередь концептуальная модель, хотя она традиционно и называется "моделью данных"). В РМД "аналогом" стала попытка применения концепции ключей. Но не удалось (к сожалению) соединить математическую модель абстрактных данных (отношение) с концептуальной моделью то ли сущностей и связей, то ли только сущностей (ключи). В ДОМД (чтобы не путать с ОМД на принципах ООП) используются объекты и связи между ними M={O,R}, O={o}, R={r} Это придумал не я. Изучайте теорию баз данных, а не формулы. Объект (перечитайте известную Вам дискуссию в части моего "спора" с U-gene, чтобы освежить в памяти что такое абстрактные и конкретные объекты) представляется идентификатором (это идентификатор объекта, а не экземпляра !), именем, способом конкретизации экземпляров (идентификации) и (не обязательно) набором характеристик o->(io,no,k,{ho}) Это придумал не я. Изучайте теорию баз данных, а не формулы. Связь представляется идентификаторами связываемых объектов, идентификатором связи, именами связей в обоих направлениях и (не обязательно) набором характеристик r->(io1,io2,ir,n1,n2,{hr}) Это придумал не я... Характеристика (и объекта, и связи) представляется идентификатором, именем, типом и другими атрибутами в зависимости от реализации самой ДОМД и реализации типов h->(ih,nh,th,{atr}) И это тоже придумал не я... Ну а собственно экземпляры объектов и связей я уже "формулизовывал" не один раз, как и стандартные операции манипулирования... Ну вот, примерно в десятый раз "представили" ДОМД. Чтобы понять ее мощь нужна, конечно, практика. Причем сравнительная. У меня она есть. А у Вас, вероятно, нет. До сих пор я не встречал ни одного приложения, для которого РМД могла бы использоваться хотя бы на равных с ДОМД... Извините, но, мне кажется, Вы не знаете элементарных вещей. Или делаете вид что не знаете ?.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2005, 18:57 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
У меня есть не новое, vadiminfo. Дело в другом. Видимо такой способ общения почему-то "подталкивает" Вас к тому, чтобы извлекать из того, что пишется, только то, с чем Вы можете "справиться", и в чем ощущаете себя знатоком. Уверен, что Вы порядочный человек. И серьезный. И при живом общении такие приемы отпадут сами собой. Если же Вы считаете, что как раз я человек не порядочный, и со мной нельзя иметь дела, то тогда да - нет смысла со мной что-то обсуждать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2005, 19:04 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Я свои аргументы по существу обсуждаемой "проблемы" привел. И всегда готов к конструктивному обсуждению. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2005, 19:07 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Андрей Леонидович У меня есть не новое, vadiminfo. Дело в другом. Видимо такой способ общения почему-то "подталкивает" Вас к тому, чтобы извлекать из того, что пишется, только то, с чем Вы можете "справиться", и в чем ощущаете себя знатоком. Опять не угадали. Я знатоком себя ни в чем не ощущаю. Я во всем сомневаюсь. Но не смотря на это, "не новые" Ваши мысли мне достаточно известны, и тем более методы их "доказательства". Зачем мне эти старые мысли? Если и раньше в них ничего рационального не нашел, то врядли, найду и позже? К тому же они в принципе не конструктивны, и потому не могут быть нигде применены. Где например, можно примеить мысль - "в РМД беда с ключами"? И тем более подобного рода доказательства? Чтобы учиться как не надо доказывать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2005, 19:28 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Не то что угадал, а прямо в точку попал. Не сомневаетесь Вы абсолютно в своих знаниях РМД и роли ключей в РМД (перечитайте свои высказывания в этой области). А говорите, что во всем сомневаетесь. И как же это понимать ? Я четко показал, скрупулезно анализируя, в частности, работы Кодда и Дейта, почему именно "беда с ключами" (перечитайте соответсвующие мои сообщения, хотя вы здесь и договорились не обращать на них внимания). И эти выводы (конечно же !) никак нельзя "применить" ни в "Р"СУБД, ни в О"Р"СУБД... Вы не то что на доказательства, а даже на сами работы автора РМД и наиболее принципиального его последователя не обращаете никакого внимания. Мысли-то Вам известны. А ответить нечем. А при живом общении придется отвечать. Вы же порядочный человек. И серьезный... Если же Вы считаете, что как раз я человек не порядочный, и со мной нельзя иметь дела, то тогда да - нет смысла со мной что-то обсуждать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2005, 21:47 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Андрей Леонидович Не сомневаетесь Вы абсолютно в своих знаниях РМД и роли ключей в РМД (перечитайте свои высказывания в этой области). А говорите, что во всем сомневаетесь. И как же это понимать ? А так и понимать, что в РМД есть еще много чего, кроме тех азбучных идей, что мы обсуждали. Там у меня есть и сомнения и непонимания. Я допускаю возможность для себя ошибок и в азбучных вещах, но в том, что Вы тут пытались проталкивать, я совсем сомневаюсь, вплоть до абсолютного нуля. Андрей Леонидович Я четко показал, скрупулезно анализируя, в частности, работы Кодда и Дейта, почему именно "беда с ключами" Ну если только скурпулезным считать что-то вырванное из контекста. Особенно интересно, что Вы верите, что они бы не увидели этой беды, а Вы показали. Да и само словосочетание какое-то не техническое. Это впору на ферме какой-нибудь дояркам втюхивать. Андрей Леонидович И эти выводы (конечно же !) никак нельзя "применить" ни в "Р"СУБД, ни в О"Р"СУБД... Про ООМД забыли, оно тоже нуждается в ключах. Тока ДОРМД не нуждается в них, как впрочем и во многом другом, скорее всего. Возьмите любую известную МД повыкидывайте из нее много, чего, а к названию припишите "Д". Скажите, что с тем что осталось у той модели просто беда, и потому полученый огрызок от модели лучше. Андрей Леонидович Вы не то что на доказательства, а даже на сами работы автора РМД и наиболее принципиального его последователя не обращаете никакого внимания. Обращаю опосредованно, через труды более продвинутых, чем я. Что же мне чтобы теорию множества изучать, обязательно труды Кантора читать? Их переработали и систематизировали. Я не собираюсь проделывать эту работу за тучу докторов и педагогов. Вы вон читаете сами, а что получается? Все наоборот Вы там поняли. Вы еще Евангилие сами почитайте и истолкуйте. Этому надо учиться лет 10. Андрей Леонидович А ответить нечем. Ну и про что после этого говорить? Если у Вас после всего поворачивается язык на такое. Вы так запросто черное белым называете не моргнув глазом. Андрей Леонидович Если же Вы считаете ... и со мной нельзя иметь дела, то тогда да - нет смысла со мной что-то обсуждать... Вот я Вам 10 раз уже говорю, что Ваши методы вести дискуссию не могут дать ничего рационального в технических вопросах. Нагибать юзеров на корявую систему, возможно, они подойдут. Или начальству запудрить мозги. Возможно, поэтому Ваша ДОМД еще не канула в лету. Если же у Вашей точки зрения есть солидные источники, дайте ссылку на литературу. Мож хоть там аргументы реальные. Тока не подбрасывайте сайт Вашей фирмы. Я его обозревал, и остался весьма недоволен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2005, 00:14 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Ничего я Вам не собираюсь подбрасывать... "Вы тут пытались проталкивать" "Это впору дояркам на ферме втюхивать" "Возьмите любую известную МД повыкидывайте из нее много, чего, а к названию припишите "Д"" "Я не собираюсь проделывать эту работу [прочитать работы Кодда - А.Л.] за тучу докторов и педагогов" "Нагибать юзеров на корявую систему" "Начальству запудрить мозги" И все это в одном сообщении... Согласен, vadiminfo - Ваши методы вести дискуссию (в отличие от моих) "рациональны в технических вопросах". Очень рациональны... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2005, 02:05 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
2 vadiminfo Парень, брось. Тут чем больше будешь спорить, тем больше распалишь товарища. И сам распалишься. Вспомни, как надо с нездоровыми обращаться: тихо, мирно, а лучше вообще игнорировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2005, 07:14 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
2 x >Опять съехали на обсуждение у кого провалы в образовании глубже и ширше, аргументы пропали, опять пошли ссылки на старые топики... Ссылки еще никому не мешали. Повторение - мать учения. (С) Если Вы не Андрей Леонидович, прочитайте те дискуссии, особеенно в начале, когда Андрею Леонидовичу, не разобравшись, еще пытались отвечать аргументированно. Статью Андрея Леонидовича тоже почитайте, на которую там ссылаются, о том что объект есть противостоящее субъекту в его какой-то там деятельности. Выскажите свои конкретные соображения, только конкретные, а не "у него аргументы, а у вас ссылки". Если Вы Андрей Леонидович, тоже прочитайте те дискуссии, это необходимо, у Вас стек переполнился. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2005, 09:02 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
softwarer Int23А почему "звезда" описывает одну сущность в строке таблицы фактов? И в строке таблицы измерений тоже. Единственно, принцип несколько нарушается с иерархиями в строгой звезде. Int23Ведь там же множество внешних ключей на размерности? И чему это противоречит? Допустим, я живу возле м. Сокол. Это - атрибут меня как сущности. Но само м. Сокол вместе со всеми его рельсами, поездами, сотрудниками, Ленинградским шоссе над и домами вокруг - моим атрибутом не является. Я с Вами согласе, но кому будет понятно то, что Вы живёте возле метро с кодовым названием 123. softwarer Int23И получается что одна строка содержит только ничего не значащие значения (внеш. ключи). А сами данные требуется получать из других таблиц. Так или я что-то не попимаю? Полагаю, Вы глобально заблуждаетесь. В первую очередь, строка таблицы содержит не столько внешние ключи, сколько значения, measures. Скажем, для факта покупки - сумму покупки. Таблицы фактов, все атрибуты которых являются измерениями - вырожденный случай; я такого, пожалуй, никогда не встречал. Можно, конечно, сделать сумму покупки измерением - но смысл? Во вторую очередь, Вы путаете форму и содержание. Вы путаете постулат "значение суррогатного ключа не несет смысловой нагрузки, не имеет физического смысла" - со смыслом наличия этого ключа в таблице фактов. Внешний ключ в таблице фактов не нужен для доступа к данным измерения. Если есть измерение, допустим, (код района, название района) - второе из этих полей нужно исключительно для целей визуализации. Никакой информации для обработки оно не несет. Если Вы захотите узнать, например, "десять районов с наибольшим объемом продаж" - Вы сделаете запрос к таблице фактов (продаж), найдете эти десять районов, а затем, может быть, для визуализации загляните в справочник и возьмете их названия. Опять же не согласен с Вами. Когда разрабатывается база данных, она предназначена для решения задач конкретной предметной области. А при описании предметной области пользователи используют привычные для них понятия (например названия районов), а уже в базе данных внешние ключи заменят названия. И разве после выполнения очередной задачи, например для выборки "десять районов с наибольшим объемом продаж" вы вернёте аналитикам таблицу с 2-я столбцами (Код района, Объём продаж). Мне кажется, что вообще не стоит говорить об отображении сущность-строка таблицы, так как это будет нарушение 1НФ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2005, 09:42 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
c127Ссылки еще никому не мешали. Повторение - мать учения. (С)Мать ..шу. Ну начинайте на пару копипастить до полного прояснения. Он свое, вы свое. Предлагаю воздержаться от повторов и отсылок к старому c127Если Вы не Андрей Леонидович, прочитайте те дискуссииЯ, конечно, не Андрей Леонидович - он за псевдонимы не прячется ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2005, 10:35 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Не врите с127. Люди же могут действительно почитать... Аргументированно не "пытались", а всегда вели диалог лишь несколько (громко сказано) человек. А Вы, как и большинство других участников "диалога", ничего никогда не аргументировали... И обострение у таких людей как Вы и mir, мне кажется вовсе не весеннее, а перманентное... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2005, 23:07 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Андрей Леонидович>Аргументированно не "пытались", а всегда вели диалог лишь несколько (громко сказано) человек. Явное переполнение стека, ничего не помнит. x>Я, конечно, не Андрей Леонидович - он за псевдонимы не прячется -Мастер? -Первый разряд. -А бъете как мастер. (С) Рассуждаете как мастер, отсюда и подозрения. Ссылки уже почитали, со Статьей ( http://www.informx.ru/seminar1.htm ) и ее обсуждением ознакомились? Зачем зря языком болтать, выскажите свои возражения по обсуждаемым вопросам, если есть что сказать. Там, например, обсуждались такие вопросы. Андрей Леонидович утверждает что статья очень хорошая. В этой статье дано определение объекта: "Объект — все, что противостоит субъекту в его предметно-практической и познавательной деятельности." Но определения субъекта в статье нет и нет ссылки на такое определение. Т.е. определение бессмысленно. Это даже не касаясь содержания определения. Что Вы можете сказать о научной статье, в которой в одном из основных определений допущена такая ошибка? Что можно сказать об авторе, который эту ошибку упрямо не признает и не приводит по этому поводу никаких аргументов вообще? Совершенно конкретные вопросы. Хоть что-нибудь по-существу можете сказать об этом? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2005, 01:42 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
с127 продолжает врать (я никогда не писал никаких статей на тему сравнения моделей данных и СУБД, а один из моих докладов на семинаре, о котором, видимо, идет речь, очень хорош, но с127 его почему-то послушать не захотел, и на семинар в далеком 1999 году почему-то не пришел; я уж не говорю о том, что мои взгляды с тех пор конечно изменились, причем в худшую для РМД и "Р"СУБД сторону), а мы продолжим по существу... softwarer: "Таблицы фактов, все атрибуты которых являются измерениями - вырожденный случай; я такого, пожалуй, никогда не встречал." А я использую при проектировании такие составные объекты (по Вашему - талицы фактов). Например, несколько упрощая Материал под ответственностью МОЛа в подразделении (A) <- Имеет остатки на конец -> Период (B) с соответствующими характеристиками связи. Здесь объект A имеет только ссылки на объекты Материал, Человек, Подразделение. Удалить (ведь речь идет о приложениях, в которых решаются и OLTP, и DSS(OLAP)) ОДИН экземпляр объекта Период удобнее и эффективнее, чем сотни тысяч экземпляров объекта в варианте с интеграцией объекта Период в составной объект. Или миллионы, если поддерживаются еще и связи Материал <- Имеет остатки на конец -> Период Партия материала <- Имеет остатки на конец -> Период ТТН <- Имеет долг на конец -> Период ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2005, 09:14 |
|
||
|
|

start [/forum/topic.php?all=1&fid=32&tid=1545856]: |
0ms |
get settings: |
6ms |
get forum list: |
17ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
30ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
109ms |
get tp. blocked users: |
1ms |
| others: | 221ms |
| total: | 404ms |

| 0 / 0 |
