Занимаюсь написанием приложения с использованием ООП,
общающегося с базой данных посредством SQL-запросов.
Вижу следующие варианты:
1. Куча SQL-запросов на все случаи жизни и головная боль
при изменении структуры базы данных.
2. Полная инкапсуляция таблиц в классы. В результате миллион
запросов в циклах и эффективность, стремящаяся к нулю.
3. Комбинация первых двух вариантов, обладающая недостатками того и другого.
Буду благодарен, если кто-либо подскажет способ избежать
всех указанных проблем.
Спасибо за внимание.

Здравствуйте, stillunnicked, Вы писали:

S>Занимаюсь написанием приложения с использованием ООП,
S>общающегося с базой данных посредством SQL-запросов.
S>Вижу следующие варианты:
S>1. Куча SQL-запросов на все случаи жизни и головная боль
S> при изменении структуры базы данных.

Ну, некоторые экстремалы так делают.

S>2. Полная инкапсуляция таблиц в классы.

S>В результате миллион запросов в циклах...
Откуда дровишки?

S>...и эффективность, стремящаяся к нулю.
Не обязательно. Например, lookup по компактным справочникам может быстрее работать в промежуточном слое, чем при выполнении JOIN.

S>3. Комбинация первых двух вариантов, обладающая недостатками того и другого.

4. Поиск по этому сайту плюс раздел "ссылки". Ключевые слова: "объектно-реляционное отображение".

Здравствуйте, stillunnicked,

А вообще предлагаю тему перенести в "Архитектуру ПО".

Здравствуйте, stillunnicked, Вы писали:

S>Занимаюсь написанием приложения с использованием ООП,
S>общающегося с базой данных посредством SQL-запросов.
S>Вижу следующие варианты:
S>1. Куча SQL-запросов на все случаи жизни и головная боль
S> при изменении структуры базы данных.
S>2. Полная инкапсуляция таблиц в классы. В результате миллион
S> запросов в циклах и эффективность, стремящаяся к нулю.
S>3. Комбинация первых двух вариантов, обладающая недостатками того и другого.
S>Буду благодарен, если кто-либо подскажет способ избежать
S>всех указанных проблем.
S>Спасибо за внимание.

А еще есть ORM в качестве примера можешь посмотреть на [N]Hibernate. Сильно облегчают жизнь. Конечно это (как правило) не бесплатно с точки зрения производительности но вполне приемлимо в большом числе случаев.

S>общающегося с базой данных посредством SQL-запросов.
S>Вижу следующие варианты:
S>1. Куча SQL-запросов на все случаи жизни и головная боль
S> при изменении структуры базы данных.

Этот путь неприемлем по определению. На все случаи жизни запросы не напишешь . К тому же, неясно, как это относится к ООП.


S>2. Полная инкапсуляция таблиц в классы. В результате миллион
S> запросов в циклах и эффективность, стремящаяся к нулю.

Я бы сказал, разумная инкапсуляция записей в экземпляры классов. Тогда класс может генерировать разумные SQL запросы, а его экземпляры представляют доступ к конкретным записям в таблице. Именно класс в этом случае будет отвечать также за поддержание целостности структуры БД. Что вы про это думаете?

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>4. Поиск по этому сайту плюс раздел "ссылки". Ключевые слова: "объектно-реляционное отображение".

За ключевые слова спасибо. По крайней мере поисковики теперь выдают полезную информацию.

"объектно-реляционное отображение" — ни за что бы не догадался так сформулировать запрос.

Здравствуйте, GarryIV, Вы писали:

GIV>А еще есть ORM в качестве примера можешь посмотреть на [N]Hibernate. Сильно облегчают жизнь. Конечно это (как правило) не бесплатно с точки зрения производительности но вполне приемлимо в большом числе случаев.

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

Здравствуйте, softilium, Вы писали:

S>>1. Куча SQL-запросов на все случаи жизни и головная боль
S>> при изменении структуры базы данных.

S>Этот путь неприемлем по определению. На все случаи жизни запросы не напишешь . К тому же, неясно, как это относится к ООП.

Да никак не относится. Просто включать в классы методы, вызывающие один большой запрос. Знаю, что коряво, но иногда это лучшее решение.

S>>2. Полная инкапсуляция таблиц в классы. В результате миллион
S>> запросов в циклах и эффективность, стремящаяся к нулю.

S>Я бы сказал, разумная инкапсуляция записей в экземпляры классов. Тогда класс может генерировать разумные SQL запросы, а его экземпляры представляют доступ к конкретным записям в таблице. Именно класс в этом случае будет отвечать также за поддержание целостности структуры БД. Что вы про это думаете?

Я и сам думал, что должны быть способы "разумной инкапсуляци", просто плохо представлял, как она выглядит.
После того как узнал, что это называется "объектно-реляционное отображение" нашел пару хороших статей. Буду разбираться.
Спасибо всем, кто откликнулся.

Купить М.Фаулер "Архитектрура корпоративных программных приложений"
Этот вопрос там подробно расмотрен

Здравствуйте, stillunnicked, Вы писали:

S>Буду благодарен, если кто-либо подскажет способ избежать
S>всех указанных проблем.
А способ изолировния всегда один, введение логического слоя. Притом этот слой может располагаться как на сервере БД(вьюхи и хранимки), так и на уровне клиента(те же ORM с различными видами мапперов). В первом случае ты можешь более гибко управлять производительностью БД, во втором ты можешь получать данные уже в объектном виде. Поэтому иногда делают и два слой, слой хранимок на бд и мапперы на клиенте.

С уважением, Gleb.

Здравствуйте, stillunnicked, Вы писали:

S>Занимаюсь написанием приложения с использованием ООП,
S>общающегося с базой данных посредством SQL-запросов.
S>Вижу следующие варианты:
S>1. Куча SQL-запросов на все случаи жизни и головная боль
S> при изменении структуры базы данных.
S>2. Полная инкапсуляция таблиц в классы. В результате миллион
S> запросов в циклах и эффективность, стремящаяся к нулю.
S>3. Комбинация первых двух вариантов, обладающая недостатками того и другого.
S>Буду благодарен, если кто-либо подскажет способ избежать
S>всех указанных проблем.
S>Спасибо за внимание.

Например InstantObjects.

S>Я и сам думал, что должны быть способы "разумной инкапсуляци", просто плохо представлял, как она выглядит.
S>После того как узнал, что это называется "объектно-реляционное отображение" нашел пару хороших статей. Буду разбираться.
S>Спасибо всем, кто откликнулся.

Поделись ссылками, плиз

Здравствуйте, GlebZ, Вы писали:

GZ>А способ изолировния всегда один, введение логического слоя. Притом этот слой может располагаться как на сервере БД(вьюхи и хранимки), так и на уровне клиента(те же ORM с различными видами мапперов). В первом случае ты можешь более гибко управлять производительностью БД,

На счет этого утверждения попробую поспорить. Если логика находится на сервере приложений, то роль БД сводится просто к чтению и записи данных — это СУБД должна уметь делать быстрее всего. А если использовать распределение нагрузки на уровне сервера приложений (запустить их несколько), то и производительностью можно будет хорошо порулить. К тому же, как мне кажется, load-balancing на уровне сервера приложений дешевле будет сделать.

Здравствуйте, stillunnicked, Вы писали:

S>Занимаюсь написанием приложения с использованием ООП,
S>общающегося с базой данных посредством SQL-запросов.
S>Вижу следующие варианты:
S>2. Полная инкапсуляция таблиц в классы. В результате миллион
S> запросов в циклах и эффективность, стремящаяся к нулю.

Я тоже так думал, оказалось — не факт. При извращенной (для прграммиста, конечно ) логике очень часто возникает необходимость в использовании курсоров. Если выгребать на сервер приложения данные и там их обрабатывать, то может оказаться даже быстрей.
При разработке своей платформы я проводил тесты на производительность: переложил на объекты одну из наиболее трудоемких операций в существующей системе — отбор товаров для покупателя. Участники: тысячи мест хранения, сотни тысяч товаров, 3 алгоритма отбора товаров, тысячи записей в журнале движения товаров (и еще кое-что). В результате получившийся код на C# работал быстрее, чем аналогичный ужас на T-SQL.

Я нашел компромис в использовании сп ТОЛЬКО! для получения данных. Тут с простотой и емкостью языка SQL трудно поспорить. Любая модификация данных — только через объекты.

Здравствуйте, hugo, Вы писали:

В догонку: а если вы добавите сюда множество (распределенных по разным серверам приложений) кешей для условно-постоянных данных, которые могут получаться в начале работы (и обновляться по какому-нить событию, см. MS SQL2005), то вы получаете n-tier и больше простора для оптимизации производительности.

Здравствуйте, hugo, Вы писали:

H>На счет этого утверждения попробую поспорить. Если логика находится на сервере приложений, то роль БД сводится просто к чтению и записи данных — это СУБД должна уметь делать быстрее всего.
1. Кроме чтения-записи есть нагрузка на канал связи между сервером приложений и базой данных
2. Внутренние языки баз данных обычно богаче чем внешний SQL, и позволяют учитывать особенности той или иной базы данных.
3. Функция баз данных не ограничивается чтением-записью. Есть также транзакции и ссылочная целостность. Для создания полноценного механизма транзакций на сервере приложений — считай придется написать базу данных.

H>А если использовать распределение нагрузки на уровне сервера приложений (запустить их несколько), то и производительностью можно будет хорошо порулить. К тому же, как мне кажется, load-balancing на уровне сервера приложений дешевле будет сделать.
Нет. Во первых, все достаточно вменяемые бд уже содержат кластеризацию. Во-вторых, существуют такие вещи как распределенное выполнение запроса. В третьих, реализация распределенной транзакции не такая уж тривиальная вещь. А ошибки в этой системе фиг найдешь но они дороги. В четвертых и самое главное, база данных обычно более узкое место чем сервера приложений. Ее приходится адаптировать под возросшую нагрузку чаще чем сервера приложений.
Сервера приложений помогают снять нагрузку с базы данных, но не подменить их. Ввод-вывод с хранилища быстрей никто не сделает.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, hugo, Вы писали:

H>>На счет этого утверждения попробую поспорить. Если логика находится на сервере приложений, то роль БД сводится просто к чтению и записи данных — это СУБД должна уметь делать быстрее всего.
GZ>1. Кроме чтения-записи есть нагрузка на канал связи между сервером приложений и базой данных
Согласен, но ИМХО не здесь самое узкое место, особено учитывая возможность настройки транкинга

GZ>2. Внутренние языки баз данных обычно богаче чем внешний SQL, и позволяют учитывать особенности той или иной базы данных.
Тоже согласен, поэтому для получения данных я использую T-SQL, но только для получения. Т.к. именно здесь особо проявляется мощь запросов, с которой трудно тягаться. Обработка типа найти min, max и прочие функции — лЁгко можно реализовать на C#. Что касается сохранения данных, то я применяю хард-кодед запросы, сгенерированные автоматом.

GZ>3. Функция баз данных не ограничивается чтением-записью. Есть также транзакции и ссылочная целостность. Для создания полноценного механизма транзакций на сервере приложений — считай придется написать базу данных.
Ссылочная целостность — это ИМХО также занятие для БД, заменить на сервере приложений это дело будет тяжко да и крайне не эффективно. А вот управление транзакциями никто не запрещает вынести на уровень приложения. И зачем переписывать БД? Например, ADO.NET позволяет использовать управление SQL-транзакциями c сервера приложений.

H>>А если использовать распределение нагрузки на уровне сервера приложений (запустить их несколько), то и производительностью можно будет хорошо порулить. К тому же, как мне кажется, load-balancing на уровне сервера приложений дешевле будет сделать.
GZ>skip... В четвертых и самое главное, база данных обычно более узкое место чем сервера приложений. Ее приходится адаптировать под возросшую нагрузку чаще чем сервера приложений.
Вот поэтому, я и считаю, что лучше вынести БЛ на уровень приложения, поскольку масштабируемость в данном случае будет лучше.


GZ>Сервера приложений помогают снять нагрузку с базы данных, но не подменить их. Ввод-вывод с хранилища быстрей никто не сделает.
Дык я вроде бы и не предлагал подменить СУБД сервером приложений Я просто сказал, что оптимизация сохраненок — это не всегда может принести эффект, т.к. в случае сложной логики с ее обработкой может более эффективно справиться сервер приложений.

Здравствуйте, hugo, Вы писали:

H>>>На счет этого утверждения попробую поспорить. Если логика находится на сервере приложений, то роль БД сводится просто к чтению и записи данных — это СУБД должна уметь делать быстрее всего.
GZ>>1. Кроме чтения-записи есть нагрузка на канал связи между сервером приложений и базой данных
H>Согласен, но ИМХО не здесь самое узкое место, особено учитывая возможность настройки транкинга
Зависит от задачи. Иногда для алгоритма нужно большое количество данных, что перегрузить через канал практически невозможно. К тому-же потенциально большое количество данных может держать только сервер базы данных.

GZ>>2. Внутренние языки баз данных обычно богаче чем внешний SQL, и позволяют учитывать особенности той или иной базы данных.
H>Тоже согласен, поэтому для получения данных я использую T-SQL, но только для получения. Т.к. именно здесь особо проявляется мощь запросов, с которой трудно тягаться. Обработка типа найти min, max и прочие функции — лЁгко можно реализовать на C#. Что касается сохранения данных, то я применяю хард-кодед запросы, сгенерированные автоматом.
Ну так и в чем противоречие со сказанным мною?

H>Например, ADO.NET позволяет использовать управление SQL-транзакциями c сервера приложений.
И управление блокировками?

GZ>>Сервера приложений помогают снять нагрузку с базы данных, но не подменить их. Ввод-вывод с хранилища быстрей никто не сделает.
H>Дык я вроде бы и не предлагал подменить СУБД сервером приложений Я просто сказал, что оптимизация сохраненок — это не всегда может принести эффект, т.к. в случае сложной логики с ее обработкой может более эффективно справиться сервер приложений.
Зависит от задачи. Оптимизация чтения при независимость от физ. модели хранения — это уже огромных плюс.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, hugo, Вы писали:

H>>>>На счет этого утверждения попробую поспорить. Если логика находится на сервере приложений, то роль БД сводится просто к чтению и записи данных — это СУБД должна уметь делать быстрее всего.
GZ>>>1. Кроме чтения-записи есть нагрузка на канал связи между сервером приложений и базой данных
H>>Согласен, но ИМХО не здесь самое узкое место, особено учитывая возможность настройки транкинга
GZ>Зависит от задачи. Иногда для алгоритма нужно большое количество данных, что перегрузить через канал практически невозможно. К тому-же потенциально большое количество данных может держать только сервер базы данных.
Необязательно все тянуть сразу. Короче говоря, вопрос реализации конкретного случая и спорить беспредметно тяжело.


GZ>>>2. Внутренние языки баз данных обычно богаче чем внешний SQL, и позволяют учитывать особенности той или иной базы данных.
H>>Тоже согласен, поэтому для получения данных я использую T-SQL, но только для получения. Т.к. именно здесь особо проявляется мощь запросов, с которой трудно тягаться. Обработка типа найти min, max и прочие функции — лЁгко можно реализовать на C#. Что касается сохранения данных, то я применяю хард-кодед запросы, сгенерированные автоматом.
GZ>Ну так и в чем противоречие со сказанным мною?
Дело не в противоречии, а в широте применения T-SQL. Не всегда его использование будет более эффективным, чем код, написанный на другом языке. А поскольку речь идет о написании БЛ в сп, то и очень часто могут сказываться неэффективность T-SQL. Кроме того, использование сервера приложений вовсе не означает возможномсть работы на нескольких различных СУБД. Поэтому, внутренние языки баз данных == внешний SQL.


H>>Например, ADO.NET позволяет использовать управление SQL-транзакциями c сервера приложений.
GZ>И управление блокировками?
А в чем проблема? У нас в проекте есть аж два вида блокировок: на уровне транзакции и на уровне подключения (сессии).

GZ>>>Сервера приложений помогают снять нагрузку с базы данных, но не подменить их. Ввод-вывод с хранилища быстрей никто не сделает.
H>>Дык я вроде бы и не предлагал подменить СУБД сервером приложений Я просто сказал, что оптимизация сохраненок — это не всегда может принести эффект, т.к. в случае сложной логики с ее обработкой может более эффективно справиться сервер приложений.
GZ>Зависит от задачи. Оптимизация чтения при независимость от физ. модели хранения — это уже огромных плюс.
Не спорю. Тока причем тут этот тезис? Поясни

Здравствуйте, Аноним, Вы писали:

S>>После того как узнал, что это называется "объектно-реляционное отображение" нашел пару хороших статей. Буду разбираться.

А>Поделись ссылками, плиз

Вот это мне показалось интересным:
http://www.citforum.ru/database/articles/strategy/
Остальные были на английском, я еще сам не разобрался какие из них полезны. Их можно много найти по словам Object Relational Mapping.

Здравствуйте, hugo, Вы писали:

H>Здравствуйте, stillunnicked, Вы писали:

S>>2. Полная инкапсуляция таблиц в классы. В результате миллион
S>> запросов в циклах и эффективность, стремящаяся к нулю.

H>Я тоже так думал, оказалось — не факт. При извращенной (для прграммиста, конечно ) логике очень часто возникает необходимость в использовании курсоров. Если выгребать на сервер приложения данные и там их обрабатывать, то может оказаться даже быстрей.
H>Я нашел компромис в использовании сп ТОЛЬКО! для получения данных. Тут с простотой и емкостью языка SQL трудно поспорить. Любая модификация данных — только через объекты.

Опыт получения данных через объекты у меня уже был. Как вспомню эти семь вложенных циклов, выполнявшихся 45 минут...
А вот с модификацией данных я подобного действительно не наблюдал. Здесь есть над чем подумать, спасибо.

S>Занимаюсь написанием приложения с использованием ООП,
S>общающегося с базой данных посредством SQL-запросов.
S> ....
S>Буду благодарен, если кто-либо подскажет способ избежать
S>всех указанных проблем.

чтобы избежать всех проблем надо не заниматься написанием приложения

простите, не удержался