Реализация БД-приложений

← →
GRAND25 © (2004-09-06 20:11) [40]

Вопрос: на хрена все эти суперпрофнавыки? Вообще, зачем воротить такую телегу в памяти рабочей станции, на которую, как правило, умные люди всегда возлагают настолько мало ответственности, насколько это возможно? Временно похранить в памяти данные в супернавороченной объектной структуре некоторое время, чтобы потом вылить это все в БД? Смысл? Выигрыш? Где?

← →
Petr V. Abramov © (2004-09-06 20:36) [41]

Второй способ сводится к dataset`ам c CachedUpdates. А если еще не полениться написать с десяток базовых форм, все разновидности ордеров/накладных клепаются без единой строчки кода.

← →
iZEN © (2004-09-06 20:57) [42]

/**GRAND25 © (06.09.04 20:11) [40]
Временно похранить в памяти данные в супернавороченной объектной структуре некоторое время, чтобы потом вылить это все в БД? Смысл? Выигрыш? Где?
*/
А если отойти от концепции один_сервер-много_клиентов и посмотреть на конфигурацию, в которой нет сервера, вообще. Только клиенты и у каждого свои данные, с которыми они работают и обменивается с другими, если приспичит.
Распределённая БД.
Накой х. одному клиенту хранить данные или иметь доступ к ним, не относящиеся к его специфике работы? Или: нужно получить данные с соседнего компа, расположенного в 5-и метрах от него, а не лезть на сервер в другом городе и спрашивать разрешения...

Унифицированная объектная реализация модели такой распределённой БД в P2P-обменах существенно экономит силы и время на сопровождение и поддержку, снижает риски из-за отказов оборудования в тысячи раз.

← →
iZEN © (2004-09-06 21:01) [43]

/**Petr V. Abramov © (06.09.04 20:36) [41]
А если еще не полениться написать с десяток базовых форм, все разновидности ордеров/накладных клепаются без единой строчки кода.
*/
Признайтесь, под "десяток базовых форм" Вы хотели сказать: "Виды" (из MVC)?
Ну, тогда уж не "базовые", а что ни на есть КОНКРЕТНЫЕ. (А то код получится слишком большой).

← →
vuk © (2004-09-06 21:03) [44]

to iZEN © (06.09.04 20:57) [42]:
>Только клиенты и у каждого свои данные, с которыми они работают
>и обменивается с другими, если приспичит.
Угу, а целостность и непротиворечивость Пушкин будет обеспечивать.

>Унифицированная объектная реализация модели такой
>распределённой БД в P2P-обменах существенно экономит силы и
>время на сопровождение и поддержку, снижает риски из-за отказов
>оборудования в тысячи раз.
Ну и? Еще где-нибудь сие применяется?

← →
Petr V. Abramov © (2004-09-06 21:03) [45]

> Унифицированная объектная реализация модели такой распределённой БД <skip>
Много геморроя для поддержания целостности при многопользовательской работе при конкуренции по записи.

← →
iZEN © (2004-09-06 21:08) [46]

/**TohaNik © (06.09.04 20:02) [39]
iZEN © (06.09.04 19:24) [38]
Ну а разве разработка модели это совсем немного...?
Наверное всетаки спор из-за того что предполагается исп-е ASP.NET
где где идеология "несколько" другая.
*/
В том-то и дело, что главное здесь: ПРАВИЛЬНО понять и описать МОДЕЛЬ, а имплементация MVC - дело второстепенное (то есть уже известное, только напильником доработать нужно).

Выразить Модель в виде COM+/EJB/JDO/etc. с маппингом на БД - вот в чём сложность. Но на то и существуют проектировщики и программисты.

← →
iZEN © (2004-09-06 21:11) [47]

to vuk © (06.09.04 21:03) [44].
Я же сказал: сервера нет и не было. О непротиворечивости данных заботится пользователь и его ПО синхронизации.
Это была гипотетическая ситуация, а в главной теме автор кажется хочет отталкиваться от классической схемы сервер_БД-клиент.

← →
iZEN © (2004-09-06 21:14) [48]

/**vuk © (06.09.04 21:03) [44]
Ну и? Еще где-нибудь сие применяется?
*/
Napster, Kazaa, Gnutella, etc. - обмен информацией на основе P2P.

← →
vuk © (2004-09-06 21:22) [49]

to iZEN © (06.09.04 21:14) [48]:
>обмен информацией на основе P2P
Применяется ли это еще где-нибудь, кроме P2P? Имелось в виду именно это.

← →
Petr V. Abramov © (2004-09-06 21:48) [50]

> О непротиворечивости данных заботится пользователь и его ПО синхронизации.
Вы представляете себе это "ПО синхронизации" и сколько нехилых по сложности задач оно должно решать? Поставьте Oracle Real Application Cluster, почитайте документацию, и Вам расхочется нагружать этим пользовательскую машину. Да, Oracle - монстр, но именно из-за того, что решает объективно сложные задачи

← →
Игорь Шевченко © (2004-09-06 22:16) [51]

Sergey_Masloff (06.09.04 18:55) [35]

Да, в этом случае, наверное, имеет смысл завести кэш нужных объектов, которые могут модифицироваться из разных мест. Именно то, что называется LazyLoad, у меня такие коллекции имеют в имени суффикс Cache, так как реализовывал я их до чтения Фаулера.
Насчет простоты реализации - все зависит от того, в какой момент изменения должны быть видимы другим участникам (другим приложениям, например), тогда можно записывать либо каждое изменение (write through) либо самое последнее (Lazy Write). Методов реализации кэша данных тоже есть и разных.

← →
Игорь Шевченко © (2004-09-06 22:20) [52]

GRAND25 © (06.09.04 20:11) [40]

> Вопрос: на хрена все эти суперпрофнавыки?

Чтобы решать задачи.

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

Умные люди строят разные модели программного обеспечения, в том числе и многозвенные.

> Смысл? Выигрыш? Где?

А Фаулера-таки надо читать. Он дядька умный.

← →
Knight © (2004-09-06 22:55) [53]

В основном ориентируюсь на следующие пункты...

1) если использую db-компоненты, то все они в RO
2) для просмотра набора данных использую дбгриды, одиночные записи вывожу в нужном виде при помощи обычных не db компонентов...
3) для добавления записей, использую форму ввода на базе не db-компонентов, на которой кнопка OK становится активной, только если все введённые значения удовлетворяют заданным условиям.
4) данные одиночной записи храню либо в виде локальных переменных, либо record"a, в зависимости от количества полей, сложности данных и наличия вспомогательной информации.

Сильно не пинайте... это мои наработки, на базе небольшого опыта работы с БД :)

db-компоненты, имею ввиду, визуальные для просмотра и редактирования.

/**vuk © (06.09.04 21:22) [49]
to iZEN © (06.09.04 21:14) [48]:
>обмен информацией на основе P2P
Применяется ли это еще где-нибудь, кроме P2P? Имелось в виду именно это.
*/
Что конкретно? MVC в P2P? БД в P2P? что_то кроме P2P?
Не понял.

P2P - это связь станция<->станция. Маршрутизаторы в сетях TCP/IP обмениваются информацией по тому же принципу.

И ещё, немножко статей о P2P: http://www.javable.com/columns/p2p/

> Игорь Шевченко ©
А теперь главный вопрос вопросов - а на фига эти сложности?
В общем-то, я подозреваю, что не от не фиг делать, и всем будет интересно, на каком классе задач это нужно

> [55] iZEN © (06.09.04 23:49)

Все те области применения, которые вы приводите, не гарантируют клиенту ничего, и это не страшно в данном случае. Ну не скачал я файл наспером ввиду недоступности (по одной из 335 причин) одной из станций - ну и ладно. Завтра авось повезет.

Но как вы предполагаете в такой архитекторе следить за уникальностью ключей? За обеспечением ссылочной целостности? При том, что каждая станция может в любой момент отвалиться, зависнуть, перегнить кабель и т.п., в том числе и в момент процедуры синхронизации? И обеспечить надежность такой системы во много раз сложнее, нежели одного отдельно взятого физического сервера.

Так о какой надежности хранения и непротиворечивости данных может идти тут речь??

Теперь ко всем: я так и не понял немного автора вопроса. Из какого набора вариантов выбор предлагается сделать (обоснованный) I или II:
I
а) использовать объектный подход
б) не использоват объекты
II
а) редактировать непосдерственно DataSet
б) на клиенте как-то хранить редактируемые данные, а потом как-то их передавать на сервер (в хранилице) "ручками" (при этом не суть важно на клиенте объекты или некий ClientDataSet)

Поделюсь своим небольшим опытом.
ПО специфике работы часто приходится реализовывать редактирование данных непосредственно в Grid. Т.е. о проблемах одновления непосредственно DataSet знаю не по наслышке.
Вообще стараюсь сейчас от этого уходить, реализовывать сохранение в БД ручками. Т.к. часто возникают огромные проблемы с сохранением записи автоматическими средствами, побеждать которые учень трудно. Я уже не говорю о проблемах проверки корректности данных с выдачей понятной оператору диагностики - это вообще отдельная песня. Тем более когда работа с БД идет через SP - вообще гаси свет.
В простейших случаях (редактирование одной таблицы) однако подход с DB-aware компонентами позволяет существенно ускорить работу. Но как только нужна минимальная проверка и т.п. - все, туши свет.

Заметьте, я не говорю ни о каких объектах, т.е. не затрагиваю проблему как именно храню/обрабатываю данные, редактируемые оператором. Т.е. для меня проблема выбора - это II. В I - это не проблема в том смысле, что тут наворотить можно что хочешь, все равно никто тебя не ограничивает (кроме времени). А вот во второй делеме - тут есть внешние ограничители определенной, не поддающейся изменению логики, зашитой в VCL.

← →
Sergey_Masloff (2004-09-07 09:28) [58]

Игорь Шевченко © (06.09.04 22:16) [51]
Sergey_Masloff (06.09.04 18:55) [35]

>Да, в этом случае, наверное, имеет смысл завести кэш нужных >объектов, которые могут модифицироваться из разных мест.
Так и сделано

>так как реализовывал я их до чтения Фаулера.
Аналогично. Если б раньше прочел сэкономил бы много времени

>Методов реализации кэша данных тоже есть и разных.
Да это понятно. Но получается в любом случае сложная логика.
То есть (например при поиске):
1) Лезем в базу и ищем допустим ИВАНОВА
2) Получаем список который нужно показать пользователю чтобы он выбрал конкретного ИВАНОВА ИВАНА
3) Проверить есть ли он в кэше
4) Если есть то увеличить ему счетчик ссылок если нет то поднять в кэш
5) Дать команду на отображение данных

Это минимальный набор, проще уже некуда. Все равно получается не слишком просто.

Основной же сложностью для меня еще раз скажу является операция которая изменяет (по определению) состояние объекта в базе.

Пример:
VIEW DOCUMENT DBLAYER STORAGE
Пользователь->Вызвана команда-> Обращение -> Выполнение ХП
ввел число и Calculate() к XP Calc()
нажал расчет

И потом обратный ход -> Документ после Calculate() должен
снова поднять себя из базы (так как он не может знать что конкретно изменилось в базе) -> После этого нужно обновлять VIEW
Вобщем получается накладно. Сейчас это работает но проект имеет тенденции к еще более усложненной схеме и вобщем трудозатраты растут.
Все чего бы я пока хочу - просто отделить VIEW от DOC полностью - но тут же возникает проблема что логика DOC на 80% нигде кроме базы реализована быть не может а тогда зачем он - просто буфер с данными которые потом дублируются при отображении?

> а в главной теме автор кажется хочет отталкиваться от классической
> схемы сервер_БД-клиент.

Да, именно так и стоит задача. Никакой распределенности и раскиданности по городам.

Реализация БД-приложений Найти похожие ветки