Извините, если спрошу чушь. Есть база данных с разными таблицами. Как прикрутить модули для обработки этих данных, чтоб расширяемость была, т.е. чтоб обрабатывать ноывй формат данных просто сделал что-то(что я и спрашиваю). Модули будут писаться с помощью WWF.
Помогите, а то хочется, что-то покрасивее
Здравствуйте, na1s, Вы писали:
N>Извините, если спрошу чушь. Есть база данных с разными таблицами. Как прикрутить модули для обработки этих данных, чтоб расширяемость была, т.е. чтоб обрабатывать ноывй формат данных просто сделал что-то(что я и спрашиваю). Модули будут писаться с помощью WWF. N>Помогите, а то хочется, что-то покрасивее
Никто не знает?
Не вы один таким вопросом задаетесь Опишу чисто мое мнение.
Я работаю с базой около двух лет, довольно неплохо стал только сейчас разбираться. Так вот, почитав Тома Кайта, я пришел к выводу, что то, что касается бизнесс-логики, лучше писать на стороне базы данных, а в приложении ее сокращать до минимума. Почему? Потому что на уровне базы оно работает быстрее, и это, собственно ее задача — хранить и обрабатывать данные.
Здравствуйте, na1s, Вы писали:
N>Извините, если спрошу чушь. Есть база данных с разными таблицами. Как прикрутить модули для обработки этих данных, чтоб расширяемость была, т.е. чтоб обрабатывать ноывй формат данных просто сделал что-то(что я и спрашиваю). Модули будут писаться с помощью WWF. N>Помогите, а то хочется, что-то покрасивее
Здравствуйте, __kain, Вы писали:
__>Здравствуйте, na1s, Вы писали:
N>>Никто не знает?
__>Не вы один таким вопросом задаетесь Опишу чисто мое мнение.
__>Я работаю с базой около двух лет, довольно неплохо стал только сейчас разбираться. Так вот, почитав Тома Кайта, я пришел к выводу, что то, что касается бизнесс-логики, лучше писать на стороне базы данных, а в приложении ее сокращать до минимума. Почему? Потому что на уровне базы оно работает быстрее, и это, собственно ее задача — хранить и обрабатывать данные.
Том Кайт очень грамотный DBA. Как можно начитавшись материалов по администрированию БД делать выводы об архитектуре приложений?
"ее задача — хранить и обрабатывать данные" — согласен на все 100%, бизнес-логика тут причем?
Здравствуйте, Ziaw, Вы писали:
Z>Том Кайт очень грамотный DBA. Как можно начитавшись материалов по администрированию БД делать выводы об архитектуре приложений?
Z>"ее задача — хранить и обрабатывать данные" — согласен на все 100%, бизнес-логика тут причем?
Я размышляю так. Бизнесс-логика — это, по сути, программная прослойка на пути данных от источника к приемнику. Мы проверяем данные, добавляем что-то, проверяем, и т.д. Если так, то эти всевозможные проверки можно осуществлять с помощью объектов БД — процедур, объектов, функций. Вот и получается логика на уровне базы.
Если я не прав — поправьте Всегда рад послушать более опытных товарищей
Здравствуйте, linker, Вы писали:
L>Здравствуйте, na1s, Вы писали:
N>>Извините, если спрошу чушь. Есть база данных с разными таблицами. Как прикрутить модули для обработки этих данных, чтоб расширяемость была, т.е. чтоб обрабатывать ноывй формат данных просто сделал что-то(что я и спрашиваю). Модули будут писаться с помощью WWF. N>>Помогите, а то хочется, что-то покрасивее
L>ORM?????????? L>hibermate,Business Logic Toolkit
Как вы себе это представляете. Я создаю модуль в виде xml, а потом как его прикрутить к движку?
Здравствуйте, na1s, Вы писали:
L>>ORM?????????? L>>hibermate,Business Logic Toolkit N>Как вы себе это представляете. Я создаю модуль в виде xml, а потом как его прикрутить к движку?
Извините, тогда я не понимаю чего Вы хотите,какими-то кусками говорите свои вопросы.Скажите целиком вашу задачу и тогда ясно будет, а так не понятно чего хотите.
Здравствуйте, __kain, Вы писали:
__>Я размышляю так. Бизнесс-логика — это, по сути, программная прослойка на пути данных от источника к приемнику. Мы проверяем данные, добавляем что-то, проверяем, и т.д. Если так, то эти всевозможные проверки можно осуществлять с помощью объектов БД — процедур, объектов, функций. Вот и получается логика на уровне базы.
вот именно — можно. но лучше ли так — имхо, нет.
дело в том, что всю логику ты в базу не запихнешь, как ни старайся,
в итоге она будет размазана по нескольким слоям, что есть мега-косяк.
у меня был период, когда я так делал, это все в прошлом, сейчас БД использую только как хранилище, минимум хранимок, минимум вьюшек.
в разделе "архитектура" дофига веток по этому вопросу, если интересно — почитай, там хватает сторонников обоих подходов.
Здравствуйте, linker, Вы писали:
L>Здравствуйте, na1s, Вы писали:
L>>>ORM?????????? L>>>hibermate,Business Logic Toolkit N>>Как вы себе это представляете. Я создаю модуль в виде xml, а потом как его прикрутить к движку? L>Извините, тогда я не понимаю чего Вы хотите,какими-то кусками говорите свои вопросы.Скажите целиком вашу задачу и тогда ясно будет, а так не понятно чего хотите.
Как я понял модуль на WWF можно преобразовать в XML. ПОтом его закинуть в файл и запустить. Как?
Здравствуйте, __kain, Вы писали:
__>Я размышляю так. Бизнесс-логика — это, по сути, программная прослойка на пути данных от источника к приемнику. Мы проверяем данные, добавляем что-то, проверяем, и т.д. Если так, то эти всевозможные проверки можно осуществлять с помощью объектов БД — процедур, объектов, функций. Вот и получается логика на уровне базы.
1. описать всю бизнес-логику только на языке субд часто невозможно (как минимум часто находятся бизнес-процессы которые выходят за рамки чистой работы с субд), соответственно логика размазывается не только по слоям, но и по языкам/средствам разработки/стилям программирования.
2. внутренние языки СУБД обычно слабо поддерживают модульность, а она очень важна при разработке больших систем, легко получить тысячи процедур/вюьх/триггеров для категоризации которых используется чтонибудь типа префикса, а контроль версий обеспечивается ценой больших затрат. поддержка и сопровождение этого хозяйства будет стоить очень дорого.
3. когда данные перемешаны с логикой, могут возникнуть сложности с управлением самими данными. т.е. при работе напрямую с БД надо помнить все возможные побочные эффекты (например в виде срабатывания триггеров). (тут возможно возражение — "делайте слой таким, чтобы прямая работа с данными не требовалась", но на практике такая идиллия редко достижима)
Как видите, данный подход может усложнить как разработку так и поддержку.
Исходя из этих соображений в БД лучше всего выносить минимум логики без которого не обойтись по соображениям быстродействия (могут быть и другие причины).
С другой стороны для небольших системы с толстым клиентом (тонкого врядли получится получить без middle-tier) данный подход может быть оправдан как облегчающий в некоторых случаях апгрейд системы.
Z> 2. внутренние языки СУБД обычно слабо поддерживают модульность, а она очень важна при разработке больших систем, легко получить тысячи процедур/вюьх/триггеров для категоризации которых используется чтонибудь типа префикса, а контроль версий обеспечивается ценой больших затрат. поддержка и сопровождение этого хозяйства будет стоить очень дорого.
Вот тут я наверное прокололся У нас-то Oracle стоит — а это PL/SQL, на которам olap у Oracle написан... С другой стороны, зачем воротить сложное приложение на плохой БД?
Z>С другой стороны для небольших системы с толстым клиентом (тонкого врядли получится получить без middle-tier)
Хм, а мне наоборот кажется, что крупные проекты лучше с логикой БД делать, а в мелких можно и в приложении данные обрабатывать.. Вот у нас, в АСУ, какое бы кривое оно не было, за счет того, что работа с данными идет через процедуры БД (пакеты, ...), удается упростить логику программ и обеспечить валидность данных... Размер БД > 40 гб.
В общем это уже дикий офтоп пошел.. Нужно в философию переезжать =)
Здравствуйте, __kain, Вы писали:
Z>> 2. внутренние языки СУБД обычно слабо поддерживают модульность, а она очень важна при разработке больших систем, легко получить тысячи процедур/вюьх/триггеров для категоризации которых используется чтонибудь типа префикса, а контроль версий обеспечивается ценой больших затрат. поддержка и сопровождение этого хозяйства будет стоить очень дорого.
__>Вот тут я наверное прокололся У нас-то Oracle стоит — а это PL/SQL, на которам olap у Oracle написан... С другой стороны, зачем воротить сложное приложение на плохой БД?
как Oracle избавит от "тысячи процедур/вюьх/триггеров для категоризации которых используется чтонибудь типа префикса, а контроль версий обеспечивается ценой больших затрат". С процедурами с горем пополам справится механизм packages, но и у него есть свои недостатки.
Z>>С другой стороны для небольших системы с толстым клиентом (тонкого врядли получится получить без middle-tier) __>Хм, а мне наоборот кажется, что крупные проекты лучше с логикой БД делать, а в мелких можно и в приложении данные обрабатывать.. Вот у нас, в АСУ, какое бы кривое оно не было, за счет того, что работа с данными идет через процедуры БД (пакеты, ...), удается упростить логику программ и обеспечить валидность данных... Размер БД > 40 гб.
если я правильно понял, вы описали ситуацию с кучей разномастных программ которые работают с одной БД, в этом случае действительно единственное место для логики это сервер БД. Это не крупный проект, это как раз множество мелких с толстым клиентом.
(размер БД ничего не говорит о сложности логики)
Здравствуйте, Ziaw, Вы писали:
Z>если я правильно понял, вы описали ситуацию с кучей разномастных программ которые работают с одной БД, в этом случае действительно единственное место для логики это сервер БД. Это не крупный проект, это как раз множество мелких с толстым клиентом. Z>(размер БД ничего не говорит о сложности логики)
Я бы не стал утверждать, что они разномастные. Да, АСУ состоит из различных подсистем — управление кадрами, бухгалтерия, ... Но все они тесно взаимосвязаны. Изменение данных в кадровой системе коснется бухгалтерской части, где начисляется зарплата, и в рабочих планах, где расчитывается рабочая нагрузка на отдельного человека, в оплате за обучение, где в зависимости от данных человека и бух системы расчитывается тариф оплаты...
Все объекты БД рассортированы по схемам, которые соответствуют их функциональным назначениям. В каждой схеме не больше 20 таблиц + ~10 вьюх. Вполне контролируемое число. Получается как в C# — объектов много, но все они расфасованы по namespace — ам.
Опишу чисто мое мнение.
