|
|
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
Допустим есть модель концептуальная (логическая) Получить физическую из неё для разных СУБД не проблема. Но это будут только таблицы. А как быть с ХП и прочими подобными вещами? Как ведется идентичность логики для двух разных СУБД? просто тупо дублируется код с учетом особенностей каждой из СУБД? Или в таких случаях бизнес логика выносится из сервера БД на сервер приложений или на клиента? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2007, 09:49 |
|
||
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
minvaА как быть с ХП и прочими подобными вещами? Как ведется идентичность логики для двух разных СУБД?Есть три варианта: 1) Из многих СУБД выбрать одну и для нее делать 2) Поддерживать две разные версии СУБД - как разные продукты 3) Вынести логику в сервер приложений (или на клиента) Все подходы имеют свои недостатки и не маленькие. Вобщем, независимость приложения от СУБД - это миф. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2007, 10:01 |
|
||
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
Есть четвертый. Разработать свой диалект языка написания запросов/ХП и реализовать транслятор с него на языки используемых БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2007, 10:33 |
|
||
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
minva 1. просто тупо дублируется код с учетом особенностей каждой из СУБД 2. бизнес логика выносится из сервера БД на сервер приложений ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2007, 13:45 |
|
||
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
Независимость должна обеспечиваться в соответствии с каким-то стандартом, например ANSI SQL92(99). Многие СУБД поддерживают ANSI, но только "начальный уровень". Поэтому независимость можно обеспечить в метаданных(и то придется покоптеть, ибо в некоторых СУБД нет триггеров, ХП, доменов, другие типы данных) и простых запросах. Собственно сам хочу создать модуль-транслятор моего метаязыка в метаданные для конкретной СУБД, остальное писать в виде плагина под конкретную СУБД. Не стоит имхо гнаться за излишней универсальностью, надо четко разграничить то, что можно автоматизировать(метаданные, простые выборки), и то, что лучше делать индивидуально под каждую СУБД. ----- Проходя мимо разложенных граблей, ты теряешь драгоценный опыт. (с) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2007, 12:47 |
|
||
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
softwarerЕсть четвертый. Разработать свой диалект языка написания запросов/ХП и реализовать транслятор с него на языки используемых БД. Хм..мне кажется написание это транслятора выйдет очень дорого.Опять все хотят изобретать велосипед ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2008, 20:43 |
|
||
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
глупый вопрос - а зачем это надо??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2008, 21:26 |
|
||
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
Оптимист_оракулХм..мне кажется написание это транслятора выйдет очень дорого. "Кажется" - категория крайне неудачная с точки зрения осмысленного принятия решений. "Очень дорого" - слова, не имеющие смысла (сколько это - 1e3? 1e6? 1e9? 1e12?) Для большой системы - трудоемкостью в сотни и тысячи человеко-лет - создание такого транслятора будет кардинально дешевле, нежели аккуратный перевод написанного на несколько других диалектов и дальнейшая согласованная поддержка. Для маленькой системы - трудоемкостью, скажем, в один человеко-год - кардинально дороже. Дальше следует искать оптимум. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2008, 21:37 |
|
||
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
minva<...>А как быть с ХП и прочими подобными вещами?<...> Либо избегать, либо поддерживать отдельно для каждой поддерживаемой СУБД. Не так ведь много нужно: либо Oracle + MS SQL, либо Firebird + PostgreSQL, их последнюю 1 версию. Остальные умирают или влачат. minva Как ведется идентичность логики для двух разных СУБД? просто тупо дублируется код с учетом особенностей каждой из СУБД? Либо так, либо прокрустово ложе SQL/92, да и то не без учёта специфики. minva Или в таких случаях бизнес логика выносится из сервера БД на сервер приложений или на клиента? Можно, конечно, и так, но есть много противников этого подхода. Производители СУБД не зря старались напихать в них всяческих несвойственных "вкусностей", имеющих весьма посредственное отношение к хранению данных. Вряд ли у Вас получится лучше (дешевле, быстрее, качественнее), чем у них. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2008, 01:36 |
|
||
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer пишет: > Для большой системы - трудоемкостью в сотни и тысячи человеко-лет - > создание такого транслятора будет кардинально дешевле, нежели аккуратный > перевод написанного на несколько других диалектов и дальнейшая > согласованная поддержка. Для маленькой системы - трудоемкостью, скажем, > в один человеко-год - кардинально дороже. Дальше следует искать оптимум. Т.е. нам надо писать ... А я отбрыкивался ... Есть такой на примете ? Делись давай ... Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2008, 15:19 |
|
||
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
MasterZivТ.е. нам надо писать ... А я отбрыкивался ... Хм. Скажем так, в командах, у которых это будет оправдано, как правило умеют подсчитывать стоимость и искать оптимальные решения :) MasterZivЕсть такой на примете ? ABAP какой-нибудь... не интересовался. MasterZivДелись давай ... Да без проблем. Заказывайте - напишем ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2008, 16:10 |
|
||
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer пишет: > Да без проблем. Заказывайте - напишем ловлю на слове. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2008, 18:47 |
|
||
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
Подскажите пожайлуста практическую ценность такого транслятора? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2008, 23:21 |
|
||
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
Оптимист_оракулПодскажите пожайлуста практическую ценность такого транслятора? наверное нужно пять в зачотку ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2008, 23:23 |
|
||
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
minvaА как быть с ХП и прочими подобными вещами? Как ведется идентичность логики для двух разных СУБД? просто тупо дублируется код с учетом особенностей каждой из СУБД? 1. Использовать ORM-средства и Mapping-helper-ы (Hibernate/NHibernate, iBatis, LINQ ...) и отказаться от слоя хп и какой-либо бизнес-логики на стороне СУБД. 2. Выносить в хп только CRUD-слой который может быть 100% перегенерирован для конкретной СУБД на основе модели. ... Примеры реализаций упоминаемых трансляторов: HQL (Hibernate), LINQ To SQL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2008, 00:48 |
|
||
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
Megabyte Собственно сам хочу создать модуль-транслятор моего метаязыка в метаданные для конкретной СУБД, остальное писать в виде плагина под конкретную СУБД. Не стоит имхо гнаться за излишней универсальностью, надо четко разграничить то, что можно автоматизировать(метаданные, простые выборки), и то, что лучше делать индивидуально под каждую СУБД. Ключевые слова: yacc, lex и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2008, 03:39 |
|
||
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
>Роман Дынник >1. ... отказаться от слоя хп и какой-либо бизнес-логики на стороне СУБД. ... >2. Выносить в хп только CRUD-слой ... Делаю аналогично: - на стороне СУБД нет серьёзной бизнес-логики, - создаётся выделенный CRUD-слой. Может быть дополнен и ХП ( почти всегда для баз данных типа MSSQL и Oracle и может быть для других серверов данных) Есть одна тонкость. В своё время softwarer точно подметил - CRUD-слой то придется переписывать заново для каждого сервера данных (цитирую softwarer не дословно). А это не совсем тривиальная задача. Такая операция, как формирование страницы из полной выборки, реализуется по-разному для MSSQL и Oracle. И это видимо справедливо и для других серверов данных. Вы упоминаете типы трансляторов. Я не знаю HQL, поэтому не могу ничего сказать дельного, но что он даст, если сервер данных не реляционная СУБД. LINQ только в общих чертах - ничем пока не поможет, ибо только для MSSQL. Так что надо согластится с тезисом softwarer и быть готовым писать (переписать) свой слой CRUD для каждого нового сервера данных. Для себя задачу несколько упростил. В прототипе клиент посылает серверу приложений не SQL команды, а информацию вида = сериализованные(индекс_класса+индекс_метода+параметры). СП передает в слой CRUD аналогичную информацию. С уважением, Владимир. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2008, 11:16 |
|
||
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
ВМоисеевLINQ только в общих чертах - ничем пока не поможет, ибо только для MSSQL. 1. Можно написать лююого провайдера 2. уже пишут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2008, 12:04 |
|
||
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
MasterZiv softwarer пишет: > Да без проблем. Заказывайте - напишем ловлю на слове. И что характерно, до сих пор ни заказа, ни предоплаты..... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2008, 14:21 |
|
||
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
ВМоисеев В своё время softwarer точно подметил - CRUD-слой то придется переписывать заново для каждого сервера данных (цитирую softwarer не дословно). А это не совсем тривиальная задача Не переписывать, а перегенерировать на основе модели или метаданных - это принципиально, иначе работа по созданию такого CRUD-а не укладывается ни по времени, ни по качеству. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2008, 10:19 |
|
||
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
Владимир изложил мою мысль столь же качественно, сколь генерит собственные. Softwarer прежде всего считает, что "генерация CRUD" - в общем случае идиотизм, бессмысленная попытка следовать форме правильного приложения при противоречии ее сути. В некоторых случаях она может быть оправдана техническими особенностями - например, вспоминая классическую легенду про то, что MSSQL неэффективно работает с не-ХП кодом - не более того. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2008, 10:39 |
|
||
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer wrote: > техническими особенностями - например, вспоминая классическую легенду > про то, что MSSQL неэффективно работает с не-ХП кодом - не более того. Легенду? Я бы так не сказал :) Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2008, 13:02 |
|
||
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
softwarerSoftwarer прежде всего считает, что "генерация CRUD" - в общем случае идиотизм, бессмысленная попытка следовать форме правильного приложения при противоречии ее сути. В некоторых случаях она может быть оправдана техническими особенностями - например, вспоминая классическую легенду про то, что MSSQL неэффективно работает с не-ХП кодом - не более того. Ну понеслась старая песня... хп or not хп :) Во-первых CRUD-хп вносит дополнительный слой абстракции доступа. Во-вторых - вносит дополнительный слой безопасности в виде доступа через хп, а не прямого доступа к таблицам. В-третьих - заглянем в профайлер к БД без хп - dba повесится :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2008, 15:24 |
|
||
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
lockyЛегенду? Я бы так не сказал :) У меня нет ни достаточной квалификации, ни достаточного желания, чтобы иметь собственное мнение по этому вопросу. Попытка выяснить у сведущих скл-щиков и последующая очная ставка между ними доставила мне массу удовольствия, но если коротко, я выяснил, что "не все так просто", и категорическая постановка "делай ХП или будет плохо" далеко не всегда верна, поэтому и называю ее легендой. Роман ДынникВо-первых CRUD-хп вносит дополнительный слой абстракции доступа. Пустота не может ничего внести. "Дополнительный слой абстракции" появится только если вместо "тупого автогенерируемого кода" эти ХП начнут заполняться реальным, живым содержимым, то есть перестанут быть предметом нашего обсуждения. Роман ДынникВо-вторых - вносит дополнительный слой безопасности в виде доступа через хп, Некорректный аргумент. По сути, Вы говорите следующее: "плохо писать приложение - хорошо тем, что иначе можно было бы написать еще хуже". Я же - призываю писать хорошо. Роман ДынникВ-третьих - заглянем в профайлер к БД без хп - dba повесится :) Роман... в предыдущем аргументе Вы показали нежелание подумать над сказанным мной. В этом аргументе - демонстрируете, что либо не читали написанного мной, либо осознанно проигнорировали это. При таком отношении собеседника к разговору я в 100% случаев прекращаю беседу. Dixi. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2008, 17:15 |
|
||
|
Поддержка нескольких СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer wrote: > У меня нет ни достаточной квалификации, ни достаточного желания, чтобы > иметь собственное мнение по этому вопросу. Попытка выяснить у сведущих > скл-щиков и последующая очная ставка между ними доставила мне массу > удовольствия, но если коротко, я выяснил, что "не все так просто", и > категорическая постановка "делай ХП или будет плохо" далеко не всегда > верна, поэтому и называю ее легендой. "Переходя улицу сначала посмотри налево, дойдя до середины дороги - направо" - "легенда" из той же категории "легенд". Далеко не всегда верна. Но - справедлива и постоянно встречаются "легендарные случаи". Может быть - и не легенда это вовсе? :( Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2008, 18:03 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=35089517&tid=1544060]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
159ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
| others: | 281ms |
| total: | 522ms |
| 0 / 0 |
