Моделирование...
Евгений Подчернин
ОффТопик, пошлите, пожалуйста по адресу (в смысле, в соответствующую эху, а не
на ...). Очень хочется услышать мнения, хоть даже ругательные, по поводу моей
статьи, лежащей тут:
Большая кнопка: "Модель временных срезов".
С уважением, Евгений
Serguei Tarassov
"Евгений Подчернин" <ame...@win.chat.ru> wrote in message
news:9j0p2o$4e$23...@www.fido-online.com...
> http://amerat.narod.ru
> Большая кнопка: "Модель временных срезов".
> С уважением, Евгений
1. Общие мысли, не в плане критики Вас лично или статьи, просто наболело.
Думаю, что не открою ни для кого секрета в эхе, что в структуру типа:
Сущности(ID_сущности, Название_в_предметной_области)
Атрибуты(ID_сущности, ID_атрибута, Название_в_предметной_области)
Экземпляры(ID_сущности, ID_Экземпляра)
Значения(ID_сущности, ID_Экземпляра, ID_атрибута,
Дата_установки/изменения_значения, Значение_с_указанной_даты)
можно впихнуть все (или почти все) объекты реального мира с историей их
изменений.
Для получения информации из такой структуры будет достаточно даже начального
уровня стандарта SQL.
Вопрос. Какая модель данных и ее физическая реализация это потянет?
Вопрос не праздный. Стремление к подобным решениям наблюдаю уже лет 5, в том
числе и сам принимаю участие в той или иной степени. Упираемся в
неоптимальность реляционки для таких решений, оно и понятно. Но непонятно,
почему в других моделях должно быть лучше. Упираемся в необходимость
абстрагироваться от источников данных и в приводящую в этом случае нужду
изобретать аналог SQL для данных в "среднем слое" и сопутствующие проблемы.
По крайней мере, пока слышны (и в этой эхе) лишь маркетинговые доводы, вроде
возьмите Cache и все у вас заработает.
Очень хочу видеть ссылки на реально сделанные по такой схеме проекты ("1С" -
это антитезис, не приводите)!!! Не важно на чем, хоть на фокспро, хоть на
доморощеннной СУБД, хоть на жабе, главное, чтобы работало в промышленном
режиме.
Вопрос не менее интересный: почему при таком очевидно простом решении (4
педали и пара рычагов) никто за 30 лет не добился промышленных результатов?
Иными словами, почему мы до сих пор сидим на реляционке, если все задачи
решаются четырьмя сущностями?
2. По статье, очень бегло.
2.1. Модели и так отделены от средств реализации. Но это не значит, что
данная модель будет одинаково хорошо реализована разными средствами.
2.2. "Блочный" подход в стиле hardware-компонентов тоже не стал панацеей,
хотя и занял свое место. Тому есть несколько причин:
(1) в hardware имеем прохождение сигнала со скоростью тактовой частоты
(цифра) или света (аналог), в то время как в software время отклика на
выходе практически всегда зависит от поданной на вход информации.
(2) число возможных состояний конечного автомата в не самом сложном
бизнес-software-компоненте на порядки выше, чем в hardware-микросхеме.
Протестировать все состояния не представляется возможным за разумное время.
А если возможно, то это относительно простые компоненты вроде вычисления
математических функций или STL, для которых, опять таки, верен п(1).
Таким образом, собрав из кучи микросхем устройство мы уверены, что оно будет
работать с единой тактовой частотой. Собрав из кучи компонентов программу мы
не можем даже приблизительно оценивать время отклика на выходе.
2.3. "Прошло время программ - "черных ящиков с большой красной кнопкой" -
это противоречит принципу инкапсуляции. Она - как беременность, либо есть,
либо ее нет.
--
с уважением,
Сергей Тарасов
http://www.arbinada.com
mailto:tem...@arbinada.com
Tolik Tentser
> Вопрос не менее интересный: почему при таком очевидно простом решении (4
> педали и пара рычагов) никто за 30 лет не добился промышленных
результатов?
> Иными словами, почему мы до сих пор сидим на реляционке, если все задачи
> решаются четырьмя сущностями?
Ватсон, но это же элементарно ...
Потому, что такая структура - не решение, а перевод плоскости поиска решения
в другое место.
И понадобятся таблицы для (своих) метаданных (словарь аттрибутов) и утиль
для ими управления и т.д. и т.п.
Над этими 4-мя педалями все равно придется возводить свою полноценную
машину. Что, кстати, непросто. Хотя и реализуемо.
--
Bye ...
Тенцер А.Л.
to...@katren.ru
ICQ 15925834
Serguei Tarassov
"Tolik Tentser" <t...@katren.ru> wrote in message
news:9j15hl$ndp$1...@news.nsk.su...
> Ватсон, но это же элементарно ...
> Потому, что такая структура - не решение, а перевод плоскости поиска
решения
> в другое место.
> И понадобятся таблицы для (своих) метаданных (словарь аттрибутов) и утиль
> для ими управления и т.д. и т.п.
> Над этими 4-мя педалями все равно придется возводить свою полноценную
> машину. Что, кстати, непросто. Хотя и реализуемо.
Так возводили же не раз ;-)
И все равно - проблемы. Главным образом - по производительности.
> --
> Bye ...
> Тенцер А.Л.
> to...@katren.ru
> ICQ 15925834
Евгений Подчернин
TT> Над этими 4-мя педалями все равно придется
TT> возводить свою полноценную
TT> машину. Что, кстати, непросто. Хотя и реализуемо.
Да не так там все сложно.
Я пробую это реализовать, но я хочу знать, а стоит ли ???
Получу ли я выигрыш времени при разработке конкретного заказа ?
У 1С получилось, как бы там внутри криво не было...
--
Отправлено через сервер Talk.Ru - http://www.talk.ru
Евгений Подчернин
ST> Упираемся в необходимость
ST> абстрагироваться от источников данных и в
ST> приводящую в этом случае нужду
ST> изобретать аналог SQL для данных в "среднем слое"
Однозначно, для доступа к данным надо изобретать свой API.
ST> Очень хочу видеть ссылки на реально сделанные по
ST> такой схеме проекты ("1С" -
Если мы не сделаем, сделают за нас, лет так через 5. Далеко не все
мыслят столь же ясно, как Вы. Например, у меня на работе такие проблемы
никого не волнуют, либо не доросли, либо не задумывались.
ST> Вопрос не менее интересный: почему при таком
ST> очевидно простом решении (4
ST> педали и пара рычагов) никто за 30 лет не добился
ST> промышленных результатов?
Не было промышленной, раскрученной СУБД. Знаете, почему в России Оракл
рулит ? Все падки на маркетинговую чушь про самое-самое...
ST> Но это не значит, что
ST> данная модель будет одинаково хорошо реализована
ST> разными средствами.
Это правда. Но тут надо решить, кто сверху спит...
ST> 2.3. "Прошло время программ - "черных ящиков с
ST> большой красной кнопкой" -
ST> это противоречит принципу инкапсуляции.
Да, но это мировая практика - большая часть ошибок фиксится после
первого релиза. И главные наши тестеры - пользователи. Они же - наши
постановщики (я про ПОЛЬЗОВАТЕЛЕЙ, а не юзеров). Надо облегчить им (и
нам !!!) выполнение этой задачи.
А вообще, я просто в восторге от Вашего ответа. Я подумаю над всем
сказанным...
Belugin Max
вторник, 17 июля 2001 г., you wrote:
ST>> Упираемся в необходимость
ST>> абстрагироваться от источников данных и в
ST>> приводящую в этом случае нужду
ST>> изобретать аналог SQL для данных в "среднем слое"
ЕП> Однозначно, для доступа к данным надо изобретать свой API.
Однозначно не надо - есть масса готовых (JDO, OQL, TOPLink)
Best regards,
Max
http://belugin.newmail.ru
ICQ:9406811
Serguei Tarassov
"Belugin Max" <bel...@mail.lanit.ru> wrote in message
news:9j19q6$bdc$1...@host.talk.ru...
> ST>> Упираемся в необходимость
> ST>> абстрагироваться от источников данных и в
> ST>> приводящую в этом случае нужду
> ST>> изобретать аналог SQL для данных в "среднем слое"
> ЕП> Однозначно, для доступа к данным надо изобретать свой API.
> Однозначно не надо - есть масса готовых (JDO, OQL, TOPLink)
Это ты про что?
Можно ведь и просто SQL взять, только надо к нему интерпретатор и
оптимизатор делать для своих структур.
>
> Best regards,
> Max
> http://belugin.newmail.ru
> ICQ:9406811
--
Belugin Max
вторник, 17 июля 2001 г., you wrote:
>> ST>> Упираемся в необходимость
>> ST>> абстрагироваться от источников данных и в
>> ST>> приводящую в этом случае нужду
>> ST>> изобретать аналог SQL для данных в "среднем слое"
>> ЕП> Однозначно, для доступа к данным надо изобретать свой API.
>> Однозначно не надо - есть масса готовых (JDO, OQL, TOPLink)
ST> Это ты про что?
Это я про API
ST> Можно ведь и просто SQL взять, только надо к нему интерпретатор и
ST> оптимизатор делать для своих структур.
Если уж делать свои структуры, то нахрен делать плоскую реляционку?
Зачем повторять все недостатки SQL?
Best regards,
Max
http://belugin.newmail.ru
ICQ:9406811
--
Serguei Tarassov
"Belugin Max" <bel...@mail.lanit.ru> wrote in message
news:9j1bc9$jil$1...@host.talk.ru...
> Hello Serguei,
> ST> Это ты про что?
> Это я про API
API имеет более широкий смысл, чем просто набор интерфейсов для вызовов из
программ. SQL - это тоже API к БД.
> ST> Можно ведь и просто SQL взять, только надо к нему интерпретатор и
> ST> оптимизатор делать для своих структур.
> Если уж делать свои структуры, то нахрен делать плоскую реляционку?
> Зачем повторять все недостатки SQL?
Буква S означает STRUCTURED. То есть универсальный язык для запросов к
структурам.
О реляционке здесь пока даже не речь не шла.
В среднем слое у тебя будут структуры, хоть XML-документы, чот доморощенные
нагромождения из STL. В любом случае, для запросов к ним будет нужен аналог
SQL. Ничего принципиально не изменится, если будешь делать запросы к
объектам.
Итак, имея данные в среднем слое, нужно:
1. Выбрать структуры для их хранения (в т.ч. объектные)
2. Язык для доступа к ним
3. Эффективную реализацию языка (при инкапсуляции невозможную в принципе)
> Best regards,
> Max
>
> http://belugin.newmail.ru
> ICQ:9406811
>
>
> --
> Отправлено через сервер Talk.Ru - http://www.talk.ru
Евгений Подчернин
Ну давайте, соберемся и сделаем систему.
По два часа в день я тратить на это смогу.
Линукс ведь тоже по Интернету делался.
А потом будем на франчайзинге зарабатывать.
Это кроме шуток. Я чуствую в себе силы это сделать, но надо побольше
дискуссии, чтобы сразу максимум потенциальных проблем охватить.
Как работает 1С - франчайзи, я насмотрелся. Деньги гребут хорошие, но
их прога не масштабируется вообще. Я работаю в Электросвязи, у нас 30
удаленных филиалов - даже SQL версия не потянула.
Я хочу и могу написать лучше, только одному это не вытянуть...
Евгений Подчернин
ST> Итак, имея данные в среднем слое, нужно:
ST> 1. Выбрать структуры для их хранения (в т.ч.
ST> объектные)
ST> 2. Язык для доступа к ним
ST> 3. Эффективную реализацию языка (при инкапсуляции
ST> невозможную в принципе)
Да зачем же так сложно ???
Неужели недостаточно простого API ?
Не надо никакого языка изобретать. Бери Корбу и юзай. Это ведь будет
прикладная система, конструктор для бизнес - программ. Не так все там
сложно, чтобы писать компилятор. У меня сейчас 2 класса, там методы:
get()
set()
run()
seek()
select()
next()
ну еще пару...
Тогда я буду писать дальше - интерфейсная часть классов Entity и Oper.
А вот действительно проблема - быстродействие СУБД.
Может, все-таки Cache поковырять ?
Tolik Tentser
В чреве акулы, пойманной Tue, 17 Jul 2001 11:57:35 +0000 (UTC),
дети капитана Гранта нашли письмо на тему 'Re: Моделирование...':
>TT> Над этими 4-мя педалями все равно придется
>TT> возводить свою полноценную
>TT> машину. Что, кстати, непросто. Хотя и реализуемо.
>
>Да не так там все сложно.
Ты пробовал ?
>Я пробую это реализовать, но я хочу знать, а стоит ли ???
Сначала определись, что тебя не устраивает в традиционной модели
>Получу ли я выигрыш времени при разработке конкретного заказа ?
Певого - нет, наоборот проиграешь
Второго - скорее всего
Третьего - практически наверняка
Bye ...
Тенцер А.Л.
to...@katren.nsk.ru
ICQ 15925834
Tolik Tentser
В чреве акулы, пойманной Tue, 17 Jul 2001 11:41:21 +0000 (UTC),
дети капитана Гранта нашли письмо на тему 'Re: Моделирование...':
>И все равно - проблемы. Главным образом - по производительности.
Решаемые.
Говорю, как решивший (для себя) оные
Евгений Подчернин
Ну, у меня маленькая программа - бюджетирование - сидит на такой структуре, я
очень доволен. Там, правда, нет множественного наследования, зато есть система
разграничения доступа вплоть до конкретного документа, или атрибута. Писалось
тяжело, зато сопровождать - сказка. Реализация кривая (Оракл + PL/SQL) -
необъектный язык. Буду на Яву переползать.
> Сначала определись, что тебя не устраивает в традиционной модели
1) Зависимость бизнес - логики от структуры данных. Не люблю alter table, а
также многоэтажных запросов. Один раз такой запрос написать, зашить в класс и
забыть - это одно, а на КЛИЕНТЕ юзать SQL - геморой. Клиент не должен знать
структуры данных.
2) Сопровождение очень трудоемкое, особенно при серьезных мутациях.
3) Хочу меньше абстрактных объектов, чем много конкретных. Даже у 1C много
лишнего: есть справочники, перечисления, проводки, операции, документы,
субконто, оборотные субконто, счета, периодические реквизиты - это их тяжелое
наследство. Достаточно все реквизиты сделать периодическими и оставить только
справочники и операции - все остальное есть подмножество этих 2-х классов.
-- С уважением, Евгений
С уважением, Евгений
Lev Yunak
Serguei Tarassov <tem...@arbinada.com> сообщил в новостях
следующее:9j153r$6gm$1...@ddt.demos.su...
> 1. Общие мысли, не в плане критики Вас лично или статьи, просто наболело.
> Думаю, что не открою ни для кого секрета в эхе, что в структуру типа:
>
> Сущности(ID_сущности, Название_в_предметной_области)
> Атрибуты(ID_сущности, ID_атрибута, Название_в_предметной_области)
> Экземпляры(ID_сущности, ID_Экземпляра)
> Значения(ID_сущности, ID_Экземпляра, ID_атрибута,
> Дата_установки/изменения_значения, Значение_с_указанной_даты)
Еще забыл связи сущностей.
Рекомендую посмотреть в сторону MS Repository. Как раз оно.
Belugin Max
среда, 18 июля 2001 г., you wrote:
>> Сущности(ID_сущности, Название_в_предметной_области)
>> Атрибуты(ID_сущности, ID_атрибута, Название_в_предметной_области)
>> Экземпляры(ID_сущности, ID_Экземпляра)
>> Значения(ID_сущности, ID_Экземпляра, ID_атрибута,
>> Дата_установки/изменения_значения, Значение_с_указанной_даты)
LY> Еще забыл связи сущностей.
LY> Рекомендую посмотреть в сторону MS Repository. Как раз оно.
Кстати, в "Королевстве Delphi" была дискуссия почти на эту тему под названием "Метамодель".
Можно посомтреть, что там наговорили.
Best regards,
Max
http://belugin.newmail.ru
ICQ:9406811
Tolik Tentser
В чреве акулы, пойманной Wed, 18 Jul 2001 05:00:46 +0000 (UTC),
дети капитана Гранта нашли письмо на тему 'Re: Моделирование...':
>> Сначала определись, что тебя не устраивает в традиционной модели
>
>1) Зависимость бизнес - логики от структуры данных. Не люблю alter table, а
>также многоэтажных запросов. Один раз такой запрос написать, зашить в класс и
>забыть - это одно, а на КЛИЕНТЕ юзать SQL - геморой. Клиент не должен знать
>структуры данных.
>
>2) Сопровождение очень трудоемкое, особенно при серьезных мутациях.
Ну тогда и карты тебе в руки
>3) Хочу меньше абстрактных объектов, чем много конкретных. Даже у 1C много
>лишнего: есть справочники, перечисления, проводки, операции, документы,
>субконто, оборотные субконто, счета, периодические реквизиты - это их тяжелое
>наследство. Достаточно все реквизиты сделать периодическими и оставить только
>справочники и операции - все остальное есть подмножество этих 2-х классов.
:-)))))))
И от этих 2-х классов вырастить свое понятийное дерево.
Ты пойми, что ничего по 3 пункту ты не упростишь
Или инфологическую модель будет отображать структура таблиц - или твои
метаданные, но отобразить придется по любому все сущности, все связи и
все аттрибуты.
Serguei Tarassov
"Tolik Tentser" <to...@katren.ru> wrote in message
news:g929lto2u0fv7hj6j...@4ax.com...
> >И все равно - проблемы. Главным образом - по производительности.
> Решаемые.
> Говорю, как решивший (для себя) оные
Мы с тобой уже тут обсуждали, что твое решение не есть универсальное.
На простом примере, когда в одной фирме много товаров, но мало контрагентов,
а в другой наоборот, тебе придется переписывать множество запросов, которые
в твоей схеме кроме как на hints не работают.
Человек же задается именно критерием универсальности.
>
> Bye ...
> Тенцер А.Л.
> to...@katren.nsk.ru
> ICQ 15925834
Tolik Tentser
> > >И все равно - проблемы. Главным образом - по производительности.
> > Решаемые.
> > Говорю, как решивший (для себя) оные
> Мы с тобой уже тут обсуждали, что твое решение не есть универсальное.
А я и не претендую на универсальное решение произвольно взятой задачи
Я решаю конкретные задачи
> На простом примере, когда в одной фирме много товаров, но мало
контрагентов,
> а в другой наоборот, тебе придется переписывать множество запросов,
которые
> в твоей схеме кроме как на hints не работают.
Ты не прав. И опять берешь на себя совершенно необоснованную смелость судить
о том, в чем не смыслишь.
Ибо у меня в фирме - и товаров и контрагентов много (тысячи активных и тех и
тех)
И от того, что кого-то из них станет мало - во всяком случае медленнее оно
работать не станет. Как думаешь ?
Попробуй исходить из предположения, что оппонент не законченный кретин и кое
что все же соображает. Тогда не надо будет, в частности, сочуствовать моим
пользователям
> Человек же задается именно критерием универсальности.
Не бывает.
Serguei Tarassov
"Tolik Tentser" <t...@katren.ru> wrote in message
news:9j5jms$orc$1...@news.nsk.su...
> Hi !
> > > >И все равно - проблемы. Главным образом - по производительности.
> > > Решаемые.
> > > Говорю, как решивший (для себя) оные
> > Мы с тобой уже тут обсуждали, что твое решение не есть универсальное.
> А я и не претендую на универсальное решение произвольно взятой задачи
> Я решаю конкретные задачи
Тогда и не бей себя в грудь пяткой при обсуждении именно универсальных
подходов.
Радуйся, что твои конкретные задачи работают.
> > На простом примере, когда в одной фирме много товаров, но мало
> контрагентов,
> > а в другой наоборот, тебе придется переписывать множество запросов,
> которые
> > в твоей схеме кроме как на hints не работают.
> Ты не прав. И опять берешь на себя совершенно необоснованную смелость
судить
> о том, в чем не смыслишь.
Да где уж нам, теоретикам :)
> Ибо у меня в фирме - и товаров и контрагентов много (тысячи активных и тех
и
> тех)
> И от того, что кого-то из них станет мало - во всяком случае медленнее оно
> работать не станет. Как думаешь ?
Думаю, конечно. В отличие...
Ты в хинте завязан на жесткий план выполнения запроса. Ежели у тебя в фирме
5 контрагентов и 100000 товаров, ежу понятно, что оптимизатор выберет
сначала 5 записей просмотреть. И ежели ноборот, тоже понятно.
А вот с хинтом, извини. Как перебирал вначале 5 записей, так и будет после
50000, несмотря на то, что можно по 10 товарам пробежаться.
> Попробуй исходить из предположения, что оппонент не законченный кретин и
кое
Это ты сам про себя такое сказал :)
> > Человек же задается именно критерием универсальности.
> Не бывает.
И самолетов в 18 веке тоже не было... Да что там, самолетов, баз данных :)
> --
> Bye ...
> Тенцер А.Л.
> to...@katren.ru
> ICQ 15925834
>
>
Vladimir Matsievsky
по теме <Re: Моделирование...>
ST> И самолетов в 18 веке тоже не было... Да что там, самолетов, баз данных
ST> :)
Слова... слова... слова!..
База данных - это в том числе и амбаpные книги и иже с ними, существавшие
еще, если меня память не подводит, еще в Дpевнем Миpе, ака, Египет, Гpеция,
Рим...
Vladimir Matsievsky
Vadim Zakurdaev
Сообщение было получено <Wednesday July 18 2001>.
>> 1. Общие мысли, не в плане критики Вас лично или статьи, просто
>> наболело. Думаю, что не открою ни для кого секрета в эхе, что в
>> структуру типа: Сущности(ID_сущности, Hазвание_в_предметной_области)
>> Атрибуты(ID_сущности, ID_атрибута, Hазвание_в_предметной_области)
>> Экземпляры(ID_сущности, ID_Экземпляра)
>> Значения(ID_сущности, ID_Экземпляра, ID_атрибута,
>> Дата_установки/изменения_значения, Значение_с_указанной_даты)
LY> Еще забыл связи сущностей.
LY> Рекомендую посмотреть в сторону MS Repository. Как раз оно.
Hачинаем стpоить учетную систему. У нас пока такой ваpиант учета "всего на
свете":
Объекты:
(ID, ID_CLASS, NAME)
Под объектами понимаются и конкpетные экземпляpы чего либо, и классы этих
конкpетных экземпляpов(это объекты класса КЛАСС), и атpибуты классов
(это объекты класса АТРИБУТ), и связи между классами (это объекты класса СВЯЗЬ)
Атpибуты объектов:
связи(ссылки) с дpугими объектами (ID_OBJECT, ID_LINK, ID_PARENT)
ID_OBJECT - ID объекта любого класса
ID_LINK - ID объекта класса СВЯЗЬ
ID_PARENT - ID объекта любого класса
дpугие значения атpибутов объектов (ID_OBJECT, ID_ATTR, VALUE)
ID_OBJECT - ID объекта любого класса
ID_ATTR - ID объекта класса АТРИБУТ
VALUE - значение атpибута (пpедполагается несколько таблиц с pазными
типами VALUE (стpока, число, дата, BLOB, ...))
Стpуктуpа, пpедложенная на самом веpху, pассматpивалась в пеpвых pядах. Hо
стpемление к унивеpсальности механизмов подталкивала к пpедложенному мной
ваpианту.
Закурдаев Вадим
Serguei Tarassov
"Vladimir Matsievsky" <Vladimir....@p21.f125.n469.z2.fidonet.org>
wrote in message news:9955...@p21.f125.n469.z2.ftn...
Бери раньше - неолит. Старейшины засечки делали, статистику по охоте и
рыбалке вели. Из года в год. :)
Только, вот беда, такого понятия, как база данных, у них до последних
компьютерных времен не было...
> Vladimir Matsievsky
Serguei Tarassov
"Vadim Zakurdaev" <Vadim.Z...@f1.n5051.z2.fidonet.org> wrote in message
news:9955...@f1.n5051.z2.ftn...
> Hачинаем стpоить учетную систему. У нас пока такой ваpиант учета "всего на
> свете":
> Объекты:
> (ID, ID_CLASS, NAME)
> Под объектами понимаются и конкpетные экземпляpы чего либо, и классы этих
> конкpетных экземпляpов(это объекты класса КЛАСС), и атpибуты классов
> (это объекты класса АТРИБУТ), и связи между классами (это объекты класса
СВЯЗЬ)
> Атpибуты объектов:
> связи(ссылки) с дpугими объектами (ID_OBJECT, ID_LINK, ID_PARENT)
> ID_OBJECT - ID объекта любого класса
> ID_LINK - ID объекта класса СВЯЗЬ
> ID_PARENT - ID объекта любого класса
> дpугие значения атpибутов объектов (ID_OBJECT, ID_ATTR, VALUE)
> ID_OBJECT - ID объекта любого класса
> ID_ATTR - ID объекта класса АТРИБУТ
> VALUE - значение атpибута (пpедполагается несколько таблиц с pазными
> типами VALUE (стpока, число, дата, BLOB, ...))
>
>
> Стpуктуpа, пpедложенная на самом веpху, pассматpивалась в пеpвых pядах. Hо
> стpемление к унивеpсальности механизмов подталкивала к пpедложенному мной
> ваpианту.
А я тебе еще идейку подкину :)
Зачем тебе _класс_ в такой структуре? Чтобы потом наследования городить, в
том числе и множественные?
В реальном мире, то двух похожих объектов не бывает. Точнее, бывают, но
только в пределах точности нашего их восприятия АКА абстракция :) Такая вот
философия.
Шутка шуткой, но почему не обойтись без классов в такой структуре?
> Закурдаев Вадим
Tolik Tentser
> ST> И самолетов в 18 веке тоже не было... Да что там, самолетов, баз
данных
> ST> :)
>
> Слова... слова... слова!..
>
> База данных - это в том числе и амбаpные книги и иже с ними, существавшие
> еще, если меня память не подводит, еще в Дpевнем Миpе, ака, Египет,
Гpеция,
> Рим...
К слову - самолетов не было. И потому крепости брали при помощи лестниц. А
не дожидались 20 века, когда появится авиация, чтобы разбомбить. Потому как:
- крепость нужна сейчас
- в 20-м веке, кроме авиации - появится и ПВО
Что, клиенту предлагать подождать лет 50, когда производители БД поддержат
наши новые идеи и пожелания ?
Lev Yunak
Vadim Zakurdaev <Vadim.Z...@f1.n5051.z2.fidonet.org> сообщил в новостях
следующее:9955...@f1.n5051.z2.ftn...
> LY> Рекомендую посмотреть в сторону MS Repository. Как раз оно.
>
> Hачинаем стpоить учетную систему. У нас пока такой ваpиант учета "всего на
> свете":
Для каких целей используется это хранение? То есть как будет использоватся
это хранилище?
Насколько оправдана эта универсальность?
Vladimir Matsievsky
по теме <Re: Моделирование...>
ST>> Слова... слова... слова!..
ST>> База данных - это в том числе и амбаpные книги и иже с ними,
ST>> существавшие еще, если меня память не подводит, еще в Дpевнем Миpе,
ST>> ака, Египет, Гpеция, Рим...
ST> Бери раньше - неолит. Старейшины засечки делали, статистику по охоте и
ST> рыбалке вели. Из года в год. :)
Hо уже по этой инфоpмации запpосы можно было стpоить...
ST> Только, вот беда, такого понятия, как база данных, у них до последних
ST> компьютерных времен не было...
База данных в твоем понимании это чисто компьютеpный теpмин?
Vladimir Matsievsky
Vladimir Matsievsky
теме <Re: Моделирование...>
TT> Что, клиенту предлагать подождать лет 50, когда производители БД
TT> поддержат наши новые идеи и пожелания ?
Реализовывать нужно сейчас, на том, что есть.
До тех поp, пока пpоизводители смогут pеализовать наши и потpебителей
текущие идеи, и у нас и у потpебителей появятся новые...
Vladimir Matsievsky
Serguei Tarassov
"Vladimir Matsievsky" <Vladimir....@p21.f125.n469.z2.fidonet.org>
wrote in message news:9956...@p21.f125.n469.z2.ftn...
> ST> Только, вот беда, такого понятия, как база данных, у них до последних
> ST> компьютерных времен не было...
> База данных в твоем понимании это чисто компьютеpный теpмин?
Я же тебе говорю - были при неолите.
Но только в нашем современном понимании этого слова.
Как "приминение химического оружия" древними римлянами при выкуривании
смоляным дымом засевших в осаде врагов :)
> Vladimir Matsievsky
Serguei Tarassov
"Vladimir Matsievsky" <Vladimir....@p21.f125.n469.z2.fidonet.org>
wrote in message news:9956...@p21.f125.n469.z2.ftn...
> Реализовывать нужно сейчас, на том, что есть.
> До тех поp, пока пpоизводители смогут pеализовать наши и потpебителей
> текущие идеи, и у нас и у потpебителей появятся новые...
Если бы еще знать ВСЕ что есть :)
Ты посчитай комбинации сочетаний существующих СУБД и средств клиентской
разработки. И умножь на количество подходов к проектированию.
Так что, я рад за твой удачный практический опыт, но это доказывает только
то, что в твоем случае ЭТО работает. А в другом может и не работать. А
где-то в похожем случае совсем другое решение работает еще лучше...
Vadim Zakurdaev
Сообщение было получено <Thursday July 19 2001>.
>> Объекты: (ID, ID_CLASS, NAME)
>> Атpибуты объектов:
>> (ID_OBJECT, ID_LINK, ID_PARENT)
>> (ID_OBJECT, ID_ATTR, VALUE)
ST> Зачем тебе _класс_ в такой структуре? Чтобы потом наследования
ST> городить, в том числе и множественные? В реальном мире, то двух
ST> похожих объектов не бывает. Точнее, бывают, но только в пределах
ST> точности нашего их восприятия АКА абстракция :) Такая
ST> вот философия. Шутка шуткой, но почему не обойтись без классов в такой
ST> структуре?
ну мы то на точное отpажение pеальной жизни не пpетендуем. Мы только модель
стpоим и даже не с точностью нашего воспpиятия, а еще гpубее, с точностью
необходимой для pешения текущей задачи.
Класс здесь пpосто гpуппиpовка объектов с одинаковой стpуктыpой данных. Для
объектов каких то классов пpедусматpиваются особые механизмы помимо общих.
Закурдаев Вадим
Serguei Tarassov
"Vadim Zakurdaev" <Vadim.Z...@f1.n5051.z2.fidonet.org> wrote in message
news:9956...@f1.n5051.z2.ftn...
> ну мы то на точное отpажение pеальной жизни не пpетендуем. Мы только
модель
> стpоим и даже не с точностью нашего воспpиятия, а еще гpубее, с точностью
> необходимой для pешения текущей задачи.
> Класс здесь пpосто гpуппиpовка объектов с одинаковой стpуктыpой данных.
Для
> объектов каких то классов пpедусматpиваются особые механизмы помимо общих.
Вот оно! А ежели класс объекта динамически определять по наличию/отсутствию
в нем тех или иных свойств? :))
В SmallTalk, если я не ошибаюсь, можно передавать объект как параметр и не
типизировать его. Принимающая параметр функция сама разберется.
> Закурдаев Вадим
Andrei N.Sobchuck
ST> Доброго дня!
ST>
ST> "Vadim Zakurdaev" <Vadim.Z...@f1.n5051.z2.fidonet.org> wrote in message
ST> news:9956...@f1.n5051.z2.ftn...
>> ну мы то на точное отpажение pеальной жизни не пpетендуем. Мы только
>> стpоим и даже не с точностью нашего воспpиятия, а еще гpубее, с точностью
>> необходимой для pешения текущей задачи.
>> Класс здесь пpосто гpуппиpовка объектов с одинаковой стpуктыpой данных.
>> объектов каких то классов пpедусматpиваются особые механизмы помимо общих.
ST> в нем тех или иных свойств? :))
ST> В SmallTalk, если я не ошибаюсь, можно передавать объект как параметр и не
ST> типизировать его. Принимающая параметр функция сама разберется.
Там динамическое типизирование.
А термин " Принимающая параметр функция" не совсем верен.
Правда в диалекте Gemstone/S можна накладывать констрейны на тип объектов
сохраняемых в коллекциях.
ST>
>> Закурдаев Вадим
ST> --
ST> с уважением,
ST> Сергей Тарасов
ST> http://www.arbinada.com
ST> mailto:tem...@arbinada.com
ST>
ST>
ST>
--
Андрей Собчук
E-mail: and...@itware.com.ua
Victor Metelitsa
Serguei Tarassov wrote:
>
> Доброго дня!
>
> "Vadim Zakurdaev" <Vadim.Z...@f1.n5051.z2.fidonet.org> wrote in message
> news:9956...@f1.n5051.z2.ftn...
> > ну мы то на точное отpажение pеальной жизни не пpетендуем. Мы только
> модель
> > стpоим и даже не с точностью нашего воспpиятия, а еще гpубее, с точностью
> > необходимой для pешения текущей задачи.
> > Класс здесь пpосто гpуппиpовка объектов с одинаковой стpуктыpой данных.
> Для
> > объектов каких то классов пpедусматpиваются особые механизмы помимо общих.
> Вот оно! А ежели класс объекта динамически определять по наличию/отсутствию
> в нем тех или иных свойств? :))
> В SmallTalk, если я не ошибаюсь, можно передавать объект как параметр и не
> типизировать его. Принимающая параметр функция сама разберется.
СПРАВКА:
Smalltalk просто-напросто безтиповый язык. Там нет ничего, кроме
объектов, каждый объект может оказаться в любом месте и и какому угодно
объекту можно послать какое угодно сообщение с какими угодно
параметрами, и неважно, содержит ли его класс соответствующие методы или
нет (вот только реакция на сообщение может быть "не та", если класс
объекта "не тот" - например, будет выброшено исключение, но обработать
это нетрудно). Прибавим его способность изменяться на ходу (т.е. имеется
возможность добавлять/удалять/изменять классы и методы, порядок
наследования во время исполнения программы), и делаем вывод о его
невероятной гибкости. Он снимает множество вопросов, над которыми бьются
в этой эхе (конечно, добавляя небольшое количество новых, но они вполне
решаемы).
[Функций тоже нет, есть методы].
[Constraints в GemStone/S - это просто синтаксическое расширение,
которым совершенно не обязательно пользоваться].
Sergey Pratсh
"Serguei Tarassov" <tem...@arbinada.com> сообщил/сообщила в новостях
следующее: news:9j9crf$1u2$1...@ddt.demos.su...
> > ST> Только, вот беда, такого понятия, как база данных, у них до
последних
> > ST> компьютерных времен не было...
> > База данных в твоем понимании это чисто компьютеpный теpмин?
> Я же тебе говорю - были при неолите.
> Но только в нашем современном понимании этого слова.
> Как "приминение химического оружия" древними римлянами при выкуривании
> смоляным дымом засевших в осаде врагов :)
Я вроде вмешиваюсь в середину разговора, но я все же сделяю это:
Современные БД пордразумевают как средства сбора, накопления и хранения
информации, так и средства ее анализа и обработки (а также средства
резервного копирования, модификаци, развития и еще много чего). Тогда как
амбарная книга подразумевает только сбор и накопление информации, т.е.
первое.
--
С уважением,
Сергей Прач
=================
Please, send you private mail to: s_pr...@mail.ru