NeoAnomaly Full Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Достался программный комплекс, который работает с БД Firebird, а вместе с ним и требование добавить поддержку MSSQL, Oracle для охвата более широкого круга клиентов.   Мой уровень в области БД - это академические знания + 5-ток приложений на подобии: справочник телефонов/рецептов/пользователей/etc.   Пока знакомлюсь с проектом, но уже сейчас понимаю, что работы предстоит уйма. Нормальные формы - не, не слышали, больше похоже на объектную базу, но на FB . Аспекты реляционной модели - не, не слышали, целостность и часть бизнес логики в хранимках. В общем текущую модель под нож. Версионная миграция - набор скриптов с каждой версии на актуальную(не инкрементно) итого имеем уже сейчас ~100 скриптов. По операциям примерно следующее: много инсертов, много простых селектов и чуть меньше селектов со сложными условиями, вложенными запросами. Большинство операций по выборкам не time critical. В самом худшем случае оперировать придётся среди ~2кк записей.   Собственно вопрос в том, как всё это разгребсти и при этом не огребсти? На дальнейшей поддержке в том числе.   Благодаря тому, что вся работа с БД укладывается в SQL, представленный в FB 1.5(SQL99 на сколько я понял) от хранимок и специфичных для конкретной БД фишек собираюсь максимально дистанцироваться.   Основные интересующие моменты: 1. Как разрабатывать модель и выполнять версионную миграцию? Существуют ли какие-то erd-case средства для этого? Какие и что посоветуете? 2. Кстати комплекс на Delphi, благо большинство частей уже перевели на XE3. Поэтому, стоит ли использовать ORM или ограничиться unidac/firedac? Хочется свести рутинную писанину к минимуму как в процессе перевода проекта, так и при последующей поддержке. Всего записей: 418 | Зарегистр. 23-03-2010 | Отправлено: 21:42 15-05-2015 | Исправлено: NeoAnomaly, 21:50 15-05-2015

KDPoid Full Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору А какая архитектура используется (и планируется) в приложении ? 2-х звенная с толстым клиентом или 3-х звенная с тонким ?         Я бы посоветовал завести в базе признак версии и дальше все скрипты делать для инкрементальных изменений. Чтобы уже спокойно получить возможность апгрейда с любой версии на любую и при этом не перепроверять регулярно огромное количество скриптов.       Выбор средства моделирования, наверное, должен исходить из того, что собираемся моделировать. Если только структуру базы, то столпы: ErWin и PowerDesigner. Ну и вариантов попроще тоже полно. Если архитектуру приложений, то начинать я бы посоветовал с Rational Rose.   Практически все используют для моделирования UML, а Роза хоть и огромна, универсальна и каждому кажется избыточной, но она не даёт писать диаграммы неправильно...       Моделирование средствами Delphi мне не понравилось. (XE3) Какое-то оно нелепое... Ну и интеграция модели с кодом в Delphi мне кажется чрезмерной. Предчувствие, что коллега, пытаясь разобраться в модели, перехерачит по неосторожности весь код, - не даёт спать спокойно. Всего записей: 404 | Зарегистр. 08-08-2006 | Отправлено: 03:57 17-05-2015

KDPoid Full Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Для работы, в основном, использую PowerDesigner 16. Скрипты по модели генерировать умеет. И MSSQL и Oracle поддерживает. Firebird - нет. Изучения и освоения - требует. Автоматическая генерация скриптов мной используется изредка. Очень простые случаи, или очень сложные, чтобы выполнить черновую работу и потом дорабатывать.   Для местных форумчан определиться с выбором подходящего средства попроще, всегда же можно зайти в варезник и перепробовать всё, пока не найдётся что-то подходящее под вашу конкретную ситуацию...   Версионная модификация структуры базы у меня выглядит как выполнение скриптов на стороне сервера специально обученными людьми В случае с Oracle - специально обученными запускать sqlplus.   Миграция в другую базу - специально подготавливаемое одноразовое решение.   Опять же скрипты на стороне сервера.       Про чистый клиент-сервер:   В вашем случае, польза от промежуточного слоя, могла бы быть, например, такой: Инкапсулировать в отдельный слой специфику конкретной базы. Чтобы клиент работал с абстракциями более высокого уровня. Тогда добавление поддержки новой базы - это изготовление новой библиотеки-адаптера. При использовании разных  баз, где вы будете хранить тексты SQL запросов ? В клиенте ? Тогда каждая новая поддерживаемая база - это полный анализ всего кода, на предмет подгонки под специфику... Чего там, для планируемых вами MSSQL и Oracle, команда "взять первые 10 записей из селекта" - это совсем разный текст. И таких тонкостей - вагон и маленькая тележка.   Джойны, работа с null, автоинкрементные поля и ещё, и ещё, и ещё.... Всего записей: 404 | Зарегистр. 08-08-2006 | Отправлено: 07:00 18-05-2015 | Исправлено: KDPoid, 08:34 18-05-2015

protoror Full Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору изучай mormot http://synopse.info/forum/   Synopse mORMot is a Client-Server ORM/ODM and SOA framework. Self-sufficient set of well-documented units for creating Domain-Driven Designed (DDD) applications: database access (easy and high speed ORM persistence over any database either SQL or NoSQL - MongoDB - with a powerful SQLite3 kernel), Service Oriented Architecture (SOA, using methods or interface-based services like WCF), security, caching, testing (with mocks), logging, UI generation with i18n and reporting (with pdf export) are handled in a light, safe and fast Client-Server RESTful model using JSON over several communication protocols (including HTTP/1.1). A JavaScript engine is even available on server side. For Delphi 6 up to XE8 targeting Win32 and Win64 on server, with cross-platform clients (for any VCL/FMX/FPC target or SmartMobileStudio - AJAX), licensed under a MPL/GPL/LGPL tri-license. Всего записей: 494 | Зарегистр. 23-11-2009 | Отправлено: 16:48 18-05-2015

NeoAnomaly Full Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Для местных форумчан определиться с выбором подходящего средства попроще, всегда же можно зайти в варезник и перепробовать всё, пока не найдётся что-то подходящее под вашу конкретную ситуацию... Посмотрел ERWin & PowerDesigner, буду разбираться, но на первый взгляд PowerDesigner интуитивнее, чтоли   Цитата: изучай mormot   http://synopse.info/forum/   protoror, начал листать документацию, очень вдохновляюще написана     Цитата: Инкапсулировать в отдельный слой специфику конкретной базы. Чтобы клиент работал с абстракциями более высокого уровня. Тогда добавление поддержки новой базы - это изготовление новой библиотеки-адаптера.     Цитата: Очень хороший вопрос, при реализации аналогичного клиент-серверного проекта (FB + Ora) пришлось делать репозиторий запросов,  что имеет свои грабельки.     KDPoid, OXDBA, а вот тут вплотную подбираемся ко 2-му вопросу. Т.к. что ORM, что универсальные компоненты доступа обещают скрыть от меня специфику работы с наиболее общими элементами(такими как первые 10 записей из селекта) БД, т.е. фактически предоставив некоторую высокоуровневую абстракцию, избавив меня от реализации оной. Напомню, что от специфичных для СУБД фишек хочу максимально дистанцироваться, т.к. большинство запросов не критичны ко времени и не изобилуют выборками с участием 10-ка таблиц.   Понимаю, что общих советов тут быть не может и всё довольно специфично для структуры и запросов, но тем не менее, пробовал ли кто-нибудь использовать универсальные компоненты доступа и в частности их универсальный-sql?   Про ORM то же интересно, вообще, на форумах и в умных книжках обычно всё сводится, что ORM в .net & java быть и усиленно юзать в enterprise, но там они гораздо взрослее, чем в том же delphi.   Добавлено: По поводу 2-го вопроса про универсальные компоненты доступа и ORM.   Всё это конечно придётся попробовать перед тем, как принять решение, но хотелось бы услышать отзывы от тех, кто использовал: "использовал то-то для того-то, всё конечно хорошо, но косяки такие-то, столкнулся с тем-то и вообще выбор сделал правильный/неправильный и сейчас бы сделал так-то на своей задаче" и т.п.   Кстати, OXDBA Цитата: Очень хороший вопрос, при реализации аналогичного клиент-серверного проекта (FB + Ora) пришлось делать репозиторий запросов,  что имеет свои грабельки.   что за грабельки и как бы сделал сейчас? Всего записей: 418 | Зарегистр. 23-03-2010 | Отправлено: 12:09 19-05-2015 | Исправлено: NeoAnomaly, 12:19 19-05-2015

protoror Full Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору NeoAnomaly Цитата:  protoror, начал листать документацию, очень вдохновляюще написана   ну зато много всего бесплатно и главное что работает + техподдержка от ab на форуме, очень производительный чувак. А так я тоже начал изучать после высказывания одного товарища который написал, что очень хороша библиотека, но без бутылки водки не разберешься. Всего записей: 494 | Зарегистр. 23-11-2009 | Отправлено: 17:14 19-05-2015

KDPoid Full Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору NeoAnomaly,   К ORM в чистом виде отношусь настороженно...   Сомнение 1. Вы ведь имеете ввиду Object-Relation Mapping ? Отображение объектов в реляционную модель. Но откуда взялось утверждение, что ваши данные лучше представимы в объектной модели, а не в реляционной ? Тот, кто изначально проектировал вашу программу, делал это под Firebird, и, скорее всего, думал в терминах Firebird, соответствующим образом организовал данные и связи между ними. Тогда, зачем пытаться теперь сморщить это в объектную модель, чтобы потом, при помощи ORM, натянуть обратно на прямоугольные таблицы ? И всё только для независимости от типа СУБД ? Есть менее утомительные способы добиться желаемого   Сомнение 2. В лоб, ORM практикует один из трёх путей натянуть объекты на таблицы.(Ну, или мне известно три ) Но все они неэффективны с реляционной точки зрения, потому что отказываются от плюсов реляционной модели и пытаются работать с таблицами как с убогими объектами. И что тогда остаётся вам ? Или смириться с потерей производительности, или воспользоваться чёрным ходом в своём ORM-фреймворке  и предаться в критичных местах незамутнённому SQL. Т.е., начать писать СУБД-зависимый код... А тогда ради чего это всё ?   Итого: ORM, хороший выход, когда ваши данные действительно имеют объектную структуру, и надо как-то запихать их в реляционную СУБД. В остальных случаях - может поискать другие пути ?   Вот, OXDBA, наверное, хранит настоящие тексты запросов внутри самой базы. А для клиентского приложения тогда, работа с базой - это унифицированный вызов запроса по уникальному идентификатору.     Всего записей: 404 | Зарегистр. 08-08-2006 | Отправлено: 20:41 19-05-2015

KDPoid Full Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Ну вот, например, наше приложение - школьный журнал. В реляционной модели: Справочник учеников, справочник предметов. Основная таблица с двумя ссылками, датой и оценкой. Дополнительные индексы по дате и оценке для ускорения построения отчётов.   Операция над данными - это операция над журналом.   Наследования нет, инкапсуляция не требуется. Всё отлично ложится в реляционную модель и ущербно - в объектную.     И нафига в таком случае пытаться затолкать наши данные в объектную модель ?   Код приложения, конечно, будет объектный. Объектами в таком приложении я бы сделал действия над базой. Там бы пригодилось наследование. Налепил бы объектов занимающихся визуализацией, и выполняющих операции над журналом. Но вводить классы, для основных данных этого приложения - бессмысленно.... Они по сути своей - реляционны.   В противовес, конечно, есть задачи, в которых и сами данные, с которыми мы работаем лучше ложатся в объектную модель. Когда нам нужна инкапсуляция <и|или> наследование, стоит подумать и об ORM.   "БД - это сервисный уровень, предназначение которого хранить данные моей модели" Да.   Но кто сказал, что ваша модель данных - объектна ? Начинать надо не с "Мои данные - объекты !!!", а с "Мои данные - объекты ?" и тут уже решать может ли помочь ORM.   Но эта задача не связана с достижением независимости от СУБД. По-моему - так. (с) Винни Пух. Всего записей: 404 | Зарегистр. 08-08-2006 | Отправлено: 11:31 20-05-2015

NeoAnomaly Full Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору KDPoid, кажется, я понял о чём идёт речь, но, на мой взгляд, это мелкие, частные случаи. Т.к. если данные должны обрабатываться по более-менее сложным правилам - без инкапсуляции никуда.   Цитата: Но эта задача не связана с достижением независимости от СУБД.   Ну, всёравно так или иначе относится к DAL и способам его построения   В общем более-менее начал ориентироваться в этих вопросах, дальше буду смотреть по ситуации, для начала выберу case средство и приведу БД в нормальный вид Всего записей: 418 | Зарегистр. 23-03-2010 | Отправлено: 21:30 20-05-2015

KDPoid Full Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: ...Т.к. если данные должны обрабатываться по более-менее сложным правилам - без инкапсуляции никуда... В моей жизни - наоборот. Инкапсуляция - некоторое джентльменское соглашение, которое нарушается на каждом шагу...   NeoAnomaly, мы ведь оба используем Delphi ? Компоненты на форме - published, и их никак не сделать хотя бы protected, чтобы инкапсулировать элементы управления внутри формы и не допускать их свободную правку снаружи.   Все классы в одном юните - неявные friendly. Если вы в своём модуле попытаетесь написать: Код:   type TA = class            protected               AP : string;         end; var         A:TA;   То я в своём завсегда смогу: Код:   type TB = class(TA); // И в каком-то совершенно левом методе... procedure TAnything.DoIt; begin    TB(A).AP := 'Ну и где теперь ваша инкапсуляция ?'; end;     И в СУБД всё то же самое. Когда ваш проект переедет в MSSQL и Oracle, вы что, заведёте каждому классу свою коннекцию к базе ? Нет, ведь. Все будут ходить через одну. Т.е., любой, работающий с СУБД объект будет иметь одинаковый доступ ко всем данным.   Разводить реальную инкапсуляцию данных настолько геморрно, что мало кто это делает без действительно веских оснований   Наиболее частая практика: Объекты в памяти приложения - это как-бы одно, а данные в СУБД - совсем другое. Разные сущности, по разному устроенные.   Объекты не хранятся в базе.   Объекты хранят в базе своё состояние и используют его для инициализации. Почувствуйте разницу.   А ORM - это средство действительно попытаться хранить объекты в базе. Вдруг начать использовать ORM - это не "поменять носки". Это - поменять философию.       Всего записей: 404 | Зарегистр. 08-08-2006 | Отправлено: 07:30 21-05-2015

NeoAnomaly Full Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: В моей жизни - наоборот. Инкапсуляция - некоторое джентльменское соглашение, которое нарушается на каждом шагу...   KDPoid, я архитектуро дрочер поэтому стараюсь такое соглашение не нарушать и разводить в проекте "реальную" инкапсуляцию, за исключением случаев: "ааа, всё пропало, надо ещё вчера решение для этого крупного клиента, который появился сегодня" и т.п. и то после прошествия момента "вчера" начинается рефакторинг и реализация как следует.   Цитата: NeoAnomaly, мы ведь оба используем Delphi ? Компоненты на форме - published, и их никак не сделать хотя бы protected, чтобы инкапсулировать элементы управления внутри формы и не допускать их свободную правку снаружи. В рамках IoC и абстракций форма реализует интерфейс, чтобы с ней могли взаимодействовать все остальные, никаких прямых обращений из вне Цитата: Все классы в одном юните - неявные friendly.   strict - везде, где это положено, ну и интерфейсы конечно же Я сторонник подхода, когда лучше отрефакторить проект, чем написать: Цитата: TB(A).AP := 'Ну и где теперь ваша инкапсуляция ?';   и в своих проектах в stable бранчи не принимаю коммитов с подобным. За это начальство и не любит   Цитата: А ORM - это средство действительно попытаться хранить объекты в базе.   KDPoid, при code-first подходе да, а если использовать database-first подход? Всего записей: 418 | Зарегистр. 23-03-2010 | Отправлено: 14:57 21-05-2015

KDPoid Full Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Как говаривал, кажется, Гради Буч: "Если у вас в руках молоток, все ваши проблемы начинают походить на гвозди."   Если зайти со стороны реляционной СУБД, и начать смотреть на проблему в терминах реляционных таблиц, любая мысль об объектах покажется странной... Реляционная модель и получится.   В теории я бы агитировал за user-first подход.   Начинать не с диаграмм классов, не с разработки структуры БД, а с use-case диаграмм. А структура приложения и структура данных определится уже исходя из того, что нужно пользователю и какими способами он собирается этого добиваться Жаль, что так гладко выходит только в теории...   Как получится добиться инкапсуляции внутри Оракла или MSSQL - расскажите, какой способ выбрали. Всего записей: 404 | Зарегистр. 08-08-2006 | Отправлено: 18:04 21-05-2015

Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Разработка приложений с поддержкой нескольких типов БД

Переход по форумам  Закладки   » Компьютеры Цифровое изображение Программы Microsoft Windows UNIX Другие OS Hardware В помощь сисадмину Прикладное программирование Игры Форумные игры   » Интернет Web-программирование В помощь вебмастеру Графика Хостинг Зацените-ка!   » Тематические Ikonboard v.2 Ikonboard v.3 Invision Board Другие форумы PHP-Nuke и другие порталы Мобила   » Общие Спорт Флейм Темы по региональным встречам Музыка и Кино Юмор Литература и Живопись   » Ru.Board Новости Помощь по форуму   » Андеграунд eBookz Варезник Раздачи и акции Мобильный варезник Андеграунд Игры и фильмы   » Специальные Тестирование