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


а если широко использовать memcached, то тоже будет не большая не согласованность? 
можно часть логики бд написать, например, на PL/Perl в PostgreSQL и там управлять  memcached... ? 

Это сообщение отредактировал(а) gcc - 15.11.2010, 14:08

Ну, это уже проблема постановки рабочего процесса вообще. Не знаю, я привык, что и база (инкрементальные скрипты, процедуры/вьюхи/пр.) должн быть в сорс контроле. Бинарник должен собираться автоматом, при деплое на прод тегаться и т. д.

А так - насчёт "надёжности" базы. Если действительно бардак - то можно ж и на проде что-нибудь поменять, что потом фиг поймёшь как посинкать. Да или просто не сразу найдёшь (какой-нить тригер на неочевидной табличке, другие констрейнты и вообще схема базы уже совсем другая). Бардака надо просто избегать. Ну опять-таки - тут зависит, наверно, от конкретной организации и конкретных девелоперов оч многое..

Я не спорю, просто одно дело когда недопущение бардака обеспечивается огранизационно, регламентом - административно, и совсем  другое дело, когда это же обеспечивается технически, платформой.

Передача в саппорт  или же передача самого саппорта - есть суть смена и организации и девелоперов. Опять же состав девелоперов и методов девелопмента и технологий деплоймента может меняться, эволюционировать. Како тут избежать бардака? Отсутствие бардака возможно лишь в статике. А статики в этой жизне - мало. Да то не суть. 


Это сообщение отредактировал(а) Zloxa - 15.11.2010, 15:46

Отсутствие бардака возможно только при одном истинно вреном источнике (иначе денормализация получается ) - сорс контроле. А так - база всё равно не одна. Допустим, что скрипты для базы не заливаются в сорс контроль. Девелопер1 разрабатывает новую фичу, расширяет какую-нибудь хранимку (добавляет к ней какие-то возможности/параметры и т. д.). Девелопер2 фиксит багу на проде - меняет туж хранимку. Если всё это делается "напрямую в базе", то смёржить это нормально потом нельзя (не, ну можно, конечно, но гораздо сложнее по сравнению с нормальной организацией: всё через сорс контроль).

Проблема возможности правки кода в обход сорс контроля не SQL-специфична. Это относится и к любым некомпилируемым языкам - тоже можно "побыстрей поправить баг" и не залить в сорс контроль.

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

Любитель, проблема конкурентой модификации одного и того же исходного кода это таки одна проблема и возникает она на одном этапе жизненного цикла продукта. А проблема поиска актуального исходного кода - совсем другая, и возникает совсем на другом этапе.

Был у нас проектик. Его внедрили и сопровождали одни оутсорсеры. Все этапы велись честно. С багртрекером, описаловом всех модификаций, публикацией на сервере контроля версий. Затем они сдали все дела другим оутсорсерам. Сдали честно, всем пакетом документации, консультации и иже с ними. Те нас тоже очень долго оутсорсиили и тоже все по чесноку. Мировые бестпракстис и вся фигня. Дальше от тех аутсорсеров решили отказаться в пользу инхауса. Те сдали дела честно. С примерами, инструкциями, мегабайтами документации и переписок, архивом того, что они получили от предыдущего аутсорсера. Первая попытка самостоятельной модификации одной из форм уперлась в то, что исходник формы, забранный из папочки, где должен бы лежать последний актуальный - тупо не компилится, версия исходника не соответствует версии бинарника. Ктото, когдато отступил от регламента... и поди разбери кто. И то повезло что не скомпилился, было бы хуже если бы скомпилился, но работал не так как след. А экземпляров этой формы всего найдено всего шесть. Вдумчивым анализом из шести удалось выбрать одну, наиболее похожую на правду.
Организационно? конечно это все решается. Но разгребать в конце концов все равно технарям приходится. Жаль что и отгребать тоже. 

Что-т я всё-таки не пойму. При наличии цетнрального репозитория (в случае DVCS всё равно какой-т репозиторий считают "главным") проблемы быть не должно. Или я что-т не так думаю (а вообще, наверно, мы слишком отвлеклись от темы - всё-таки организация рабочего процесса далеко не самый главный фактор).


Ну это неправильно поставленный рабочий процесс. Билды для деплоя должны идти только через билд скрипт (с CI сервера вообще говоря). Если кто-т "собрал вручную" - это плохо. Как бороться - не знаю. На моей практике такие проблемы если и были, быстро решались. И повторно человек на теж грабли пытается не наступать.

Хранение "кода в базе" тоже не спасает (точнее - тем более не спасает). Никто не гарантирует, что база одна. Обычно энвайронментов много.

Почему не стоит пихать логику в СУБД:
1. Размазывание логики - часть логики будет репрезентативном слое, часть в СУБД. Плюс не совсем понятны зоны ответственности серверов.
2. Тот же PL/SQL или TSQL плохо подходят для реализации действительно больших модулей, да и количество фрейморков под эти языки исчезающе мало. С Java/C# ситуация лучше, но тут тоже есть свои проблемы. Вот у нас например используется Оракл 10, а Java там версии 1.4, и до современной 1.6 ее никак не обновишь. Плюс например тот же Spring не заведется под Ораклом. Куча проблем с деплойментом приложения.
3. Кэширование эффективно не сделаешь.
4. Чтобы увеличить производительность надо докупать лицензии на СУБД, а учитывая сколько стоят процессорные лицензии, то лучше не надо. А если и этого будет мало, то тут придется гемороится с организацией кластера СУБД.



Ну не надо, 99% целостности обеспечивается 3 типами констрейнов: NOT NULL, FK, UNIQUE, и перенести их в другую базу не составит труда.

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

Приведенными тобой средствами обеспечения целостности, как ты можешь обеспечить условие, что если документ сохранен, то он отражен в остатках?

Основное же средство обеспечения согласованности - реализация изоляции транзакций, в MS и Orаcle столь разнятся, что для универсализации разрабу придется забирать этот функционал на себя. А задача эта весьма и весьма не тривиальная, особенно если учитывать требование универсализации. Приложение, где не надо, не должно вставать на блокировках по чтению на MS SQL, а на оракле, наоборот, должно встать, где надо. Именно это, прежде всего, я и имел в виду. 


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

Про TSQL - не спорю.
PL/SQL.... Я уже упоминал что встречался лишь единожды, когда использования жавы было обусловлено сложностью задачи а не предпочтением разработчкика. То был модуль реализации pop3 протокола. 
Тут я действительно не совсем понимаю о чем ты.


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

Никак. Но в приведенном мной сценарии (3-х звенка), подобные вещи делаются средним звеном и на особенности СУБД никак не завязаны. А те 3 типа констрейнов что я упомянул нужны исключительно для избежания проблем при конкурентном доступе.




ИМХО ты все излишне усложняешь. Если использовать селекты которые выбирают маленькие наборы данных и короткие транзакции, то задержки на блокировках будет минимальны и не будут создавать проблем.




Это все верно, но для сколько нибудь нормального отображения ошибки и показа пользователю она должна быть сгенерирована как можно ближе к модулю отвечающему за представление. Вытаскивать из того же SQLException код ошибки и пытаться понять по нему, что пошло не так - то еще удовольствие. Совсем другое дело, если мы сами перед сохранением проверим все ли требования выполнены.




Достаточно просто сравнить количество различных средств рефакторинга для PL/SQL и Java  Я уж не упоминаю про количество всевозможных библиотек и всяких инфраструктурных вещей, типа юнит и интеграционных тестов, средств сборки и анализа кода.




Приведу, но чуть попозже.

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

Да, и я ж о том и говорю. Потому часть логики приходится дублировать. Но это дублирование - не размазывание.

Тут палка о двух концах. Я, конечно, не совсем в теме. Особо не копал, но что нарыл, то нарыл. В жавьем концепте, простейшее уточнение структуры данных, как правило требует модификации  бинов, зачастую - куда более одного. Желание производить эти рутинные операции автоматически вполне оправдано, потому жава и обросла огромнейшим арсеналом средств рефакторинга.
Что же касается различных наборов библиотек.... я уже упоминал что 99,9% прикладной логики энтерпайза - выбрать данные и сохранить результат. Мне действительно не доводилось встечаться с потребностью в обилии библиотек. И я уже упоминал, если прикладная логика имеет действительно сложную алгоритмику, ее вынос на выделенный сервер приложений вполне обоснована. Но я уже пять лет автоматизирую процессы предприятия и мне все еще такая логика не встретилась. Хотя, право же, действительно хотелось бы обосновать необходимость реализации прикладного слоя на жаве и получить новые компетенции.

Еще с одним недостатком реализации логики средствами приложения мне доводилось сталкиваться. Приходили к нам парни, крупные международники, внедряли крупную, дорогую, систему, интегрировали ее с прочим ###м, что у нас имеет место крутиться. Получилось так, что за интеграцию с разными модулями отвечали разные команды, а единый прикладной слой толи не был выделен, толи инструментарий не позволял его использовать(жава+формс). В результате получилось что в одну таблицу, разными интерфейсами сливаются документы из разных систем. И в каждом интерфейсе реализуется логика. И в некоторых она была реализована по разному. В результате мы получили систему, в которой не обеспечена согласованность данных. Данные о транзакциях не соответствуют данным об остатках, потому как документы одного типа были отражены в остатках разными способами. Вынос прикладной логики на сторону бд, позволил бы избежать этой ситуации. Если же реализовывать средствами апп.... Думаю, вполне можно было бы создать некий жава класс, который реализовывал бы эту самую необходимую логику, однако я не уверен что работать с ним было бы проще нежели работать с таблицей и не уверен, что его можно было бы сколь нибудь просто использовать из формсов, и так же не уверен, что нам бы не пришлось таки дублировать часть логики при работе с этим классом, дабы потом не анализировать уже не SQL, а java exception.

Добавлено через 6 минут и 53 секунды

заранее благодарен 

Это сообщение отредактировал(а) Zloxa - 24.11.2010, 15:46

1. Блокировки можно возложить на ORM, если мы хотим их делать на уровне СУБД.
2. Можно использовать версионирование (средствами того же ORM) и обойтись вообще без блокировок.
3. Для совсем "запущенных" случаев, никто не отменяет блокировки на уровне сервера приложений.
4. Или даже сделать небольшой СУБД зависимый модуль. В любом лучше переписать один маленький модуль, не представляет большой проблемы.
Хотя лично мне в моих приложениях всегда хватало commit/rollback. Пару раз приходилось использовать блокировки на уровне ORM и версионирование.



Ну а теперь смотри: у нас есть логика проверки согласованности данных в слое представления и точно такая же в СУБД. Профит в том чтобы держать ее и там и там я вижу только один: если какая-то сволочь залезет в базу напрямую, то данные все равно будут согласованны. Но мы же понимаем, что кроме DBA никто так делать не будет. Зато мы получаем необходимость держать эти две реализации логики проверки в согласованном состоянии.



Тут дело не только в переименовании, там еще куча всего типа выделить из класса интерфейс и заменить использование класса на использование интерфейса, заменить непосредственное создание на фабрику, окружить блок try/catch-ем и т.д. И это касается не только Java для C# тоже рефакторинг весьма богатый: IDEA Refactorings, ReSharper Refactorings. К тому же рефакторинг это не единственная фишка, там есть и анализ кода на лету, т.е. в той же IDEA мне не нужно запускать компиляцию, чтобы узнать что у меня в коде есть синтаксические ошибки. Интеллектуальный поиск по коду (find usage, call hierarchy и т.д.). Автоматическая генерация кода.




Я не говорю что их надо много, но часто бывают специфические требования типа работа с SCP, связь с другой системой через SOAP и т.д. Ну и плюс всякие мелкие утилитки, типа логгирования, коллекций и т.д.
И еще я говорил про утилиты для build lifecycle, как-то сборка, тестирование, деплой, что может предложить PL/SQL?




Это частный случай неудачной реализации. А представь в какую позу встала бы база, если бы эти альтернативно одаренные внедренцы попытались бы засунуть логику в СУБД (каждый свою собственную)  


P.S. Предлагаю тестик реализовать проверку корректности Номера банковской карты на PL/SQL и Java соответственно, номер приходит как строка.

Готов поменять свое мнение.

На неделе подогнали задачку. Жава апп+оракледб через пулл соединений. При утверждении бизнес правила бизнес пользователем, в ассинхронном режиме выполняется проверка непротиворечивости этого правила и, по результатам проверки, пользователю выдается сообщение о результате и правило утверждается.  Прикладуха коробочная от именитого вендора, заточена только и только под оракл, никакой абстракции от бд. Исходный код закрыт. Есть два инстанса, поднятых с одного дистра. На одном из них, в случае успешной проверки, статус объекта от чего-то  не переводится в утвержденный.

Мне необходимо локализовать проблему. Пытаюсь трассировать этот процесс. Открыаю фронт прикладухи, готовлю объект, запускаю скрипт, который переводит все активные сессии в режим трассировки и взводит триггер на онлогон, включающий трассировку для новых сессий. Нажимаю педаль утвердить, жду пару секунд, получаю респонз от от апп, подтверждающий отсутствие провтиворечий, отключаю трассировку. На сервере я один. Лезу в трассы... вижу там 25(!!!) многомегабайтных файлов трассировки. Т.е. в этом процессе поучаствовали 25 сессий. Пулл коннектов - браво! Это же просто шикарно. Я уже на эту задачу убил 10 часов, результат пока 0. Если я таки локализую эту проблему, я на ней столько бабла подниму - жена уже пакует чемоданы на Кипр. Если бы были не правильно выбраны технологии, я на задачу потратил бы от силы 2-4 часа.

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

Мы ЕАНы чекаем PL/SQLем. Чтобы эта процедура когда нибудь оказывалась узким местом - не могу припомнить.

Это сообщение отредактировал(а) Zloxa - 4.12.2010, 18:42

Я не про производительность. Просто мне кажется, что на PL/SQL код будет более громоздким. Во всяком случае когда я пытался нечто подобное реализовать на PL/SQL то код получился довольно громоздким.



По поводу привести пару примеров:

Если у нас 3-х звенка то выбор стратегий кеширования достаточно широк: 
а) можно просто полагаться на кеш базы
б) можно перед СУБД поставить кеширующие сервера (например Memcached), причем их количество можно безболезнено наращивать
в) можно внутри приложения использовать собственное кеширование загруженных данных и результатов вычислений
г) можно делать кеширование данных для клиентов (например сгенерированных HTML)
Если же у нас сервер приложений отвечает только за результат, то остается только а) и г). Пункт б) выпадает по понятным причинам, в) же нельзя использовать потому что не имея в слое представления бизнес логики, нет возможности корректно инвалидировать данные в кеше.
Приведу пример: есть система управления правами типа Oracle Entitlements Server, у нас есть юзер, права и роли. Чаще всего нам будет нужно для пользователя получить список его прав и проверить, есть ли у него право на некое действие/объект, так что кешировать связку человек-права вполне стоит. А теперь представь, что мы в роль добавляем еще одно право. Нам надо как минимум инвалидировать закешированные для некоторых пользователей права, а еще лучше перевычислить их. Если у нас бизнес логика в сервере приложений, то проблем нет, мы знаем как это сделать. А вот если она в СУБД, то тут уже придется помучится.





Большая часть запросов к системе идет на чтение и читающие запросы достаточно легко распараллеливаются. Поднимаем 10 бесплатных Томкатов, ставим перед ними балансировщик, поднять стендбай и у нас готово дешевое решение. А если бы мы попытались тоже самое реализовать с Ораклом, нам пришлось бы купить лицензию на Oracle RAC, потратится на SAN для RAC, ну и конечно поднять 10 Томкатов  (слой представления никуда же не делся).

LSD, спасибо за интересный ответ по существу. Определенно это материал для раздумий.

Из того, что приходит в голову на вскидку, без глубоких размышлений:

Бд может поднять алерт, по которому приложение будет сбрасывать кэш.


Хм.. но писать же в стендбай - нельзя. Хотя, наверное можно как то выкрутиться, чтобы запись производилась в мастербазу.

Вообще да, мой разум замутнен всякими разными ЕРП. Когда я говорю об энтерпрайзе, я прежде всего это имею в виду. В этом сегменте отношение количества чтений к количеству записей достаточно велико, при том что количество чтений достаточно низко, ибо количество пользователей ограничено, в отличии от всякоразных вебсервисес, где количество чтений стремится к бесконечности, количесто записей стримится к нулю.

А зачем в стендбай писать, писать надо в мастер. Организовать согласованную запись в одну базу на уровне сервера приложений не сложно.



1. Как это реализовать в Оракле без использования Явы?
2. Т.е. у нас получается, что СУБД (в данном случае это слой которой содержит бизнес логику) завязывается на слой представления.