Сообщение Re[3]: [proof-of-concept] compile time query language от 13.07.2016 9:29
Изменено 13.07.2016 9:34 chaotic-kotik
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Это лишь пример в ответ на заявления о невозможности в другой теме.
Тогда вопросов больше нет, действительно неплохая демонстрация возможностей языка
EP>Я думаю это от отсутствия массового спроса на работу с СУБД из C++. Мне вот тоже такие задачи не попадаются совсем.
Скорее tradeoffs при работе с БД немного другие и производительность достигается другими методами.
CK>>Проще вынести весь код работающий с БД в отдельный DAL слой и работать с ним.
EP>DAL как реализовывать? На каком языке/библиотеке?
EP>Где делать требуемые проекции, фильтрации? Всё в DAL расписывать?
Да, а что такого? Вынести в отдельный модуль, чтобы все приложение работало через какой-нибудь абстрактный интерфейс и не знало вообще, с чем оно работает, с БД, или еще каким-нибудь источником данных. Тут можно свапнуть БД на другую (например в тестах использовать sqlite вместо постгреса или вообще какой-нибудь nosql). Я еще в одном проекте видел такое — каждый row в результатах запроса конвертировался в boost.property_tree, который передавался кругом. Все ф-ии работающие с данными принимали property_tree, все довольно универсально и гибко было, скажем коду было не важно, пришел property_tree из базы или из POST запроса. Накладные расходы конечно большие, но это сильно лучше чем размазывать работу с БД по всему приложению и при каждом изменении схемы переписывать код и пересобирать.
EP>Это лишь пример в ответ на заявления о невозможности в другой теме.
Тогда вопросов больше нет, действительно неплохая демонстрация возможностей языка
EP>Я думаю это от отсутствия массового спроса на работу с СУБД из C++. Мне вот тоже такие задачи не попадаются совсем.
Скорее tradeoffs при работе с БД немного другие и производительность достигается другими методами.
CK>>Проще вынести весь код работающий с БД в отдельный DAL слой и работать с ним.
EP>DAL как реализовывать? На каком языке/библиотеке?
EP>Где делать требуемые проекции, фильтрации? Всё в DAL расписывать?
Да, а что такого? Вынести в отдельный модуль, чтобы все приложение работало через какой-нибудь абстрактный интерфейс и не знало вообще, с чем оно работает, с БД, или еще каким-нибудь источником данных. Тут можно свапнуть БД на другую (например в тестах использовать sqlite вместо постгреса или вообще какой-нибудь nosql). Я еще в одном проекте видел такое — каждый row в результатах запроса конвертировался в boost.property_tree, который передавался кругом. Все ф-ии работающие с данными принимали property_tree, все довольно универсально и гибко было, скажем коду было не важно, пришел property_tree из базы или из POST запроса. Накладные расходы конечно большие, но это сильно лучше чем размазывать работу с БД по всему приложению и при каждом изменении схемы переписывать код и пересобирать.
Re[3]: [proof-of-concept] compile time query language
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Это лишь пример в ответ на заявления о невозможности в другой теме.
Тогда вопросов больше нет, действительно неплохая демонстрация возможностей языка
EP>Я думаю это от отсутствия массового спроса на работу с СУБД из C++. Мне вот тоже такие задачи не попадаются совсем.
Скорее tradeoffs при работе с БД немного другие и производительность достигается другими методами.
CK>>Проще вынести весь код работающий с БД в отдельный DAL слой и работать с ним.
EP>DAL как реализовывать? На каком языке/библиотеке?
Я как правило предпочитаю нативную клиентскую библиотеку использовать ну и обычные текстовые запросы + prepare для некоторых.
EP>Где делать требуемые проекции, фильтрации? Всё в DAL расписывать?
Да, а что такого? Вынести в отдельный модуль, чтобы все приложение работало через какой-нибудь абстрактный интерфейс и не знало вообще, с чем оно работает, с БД, или еще каким-нибудь источником данных. Тут можно свапнуть БД на другую (например в тестах использовать sqlite вместо постгреса или вообще какой-нибудь nosql). Я еще в одном проекте видел такое — каждый row в результатах запроса конвертировался в boost.property_tree, который передавался кругом. Все ф-ии работающие с данными принимали property_tree, все довольно универсально и гибко было, скажем коду было не важно, пришел property_tree из базы или из POST запроса. Накладные расходы конечно большие, но это сильно лучше чем размазывать работу с БД по всему приложению и при каждом изменении схемы переписывать код и пересобирать.
И что ты понимаешь под фильтрациями? Where statement в SQL или обработку результатов запроса?
EP>Это лишь пример в ответ на заявления о невозможности в другой теме.
Тогда вопросов больше нет, действительно неплохая демонстрация возможностей языка
EP>Я думаю это от отсутствия массового спроса на работу с СУБД из C++. Мне вот тоже такие задачи не попадаются совсем.
Скорее tradeoffs при работе с БД немного другие и производительность достигается другими методами.
CK>>Проще вынести весь код работающий с БД в отдельный DAL слой и работать с ним.
EP>DAL как реализовывать? На каком языке/библиотеке?
Я как правило предпочитаю нативную клиентскую библиотеку использовать ну и обычные текстовые запросы + prepare для некоторых.
EP>Где делать требуемые проекции, фильтрации? Всё в DAL расписывать?
Да, а что такого? Вынести в отдельный модуль, чтобы все приложение работало через какой-нибудь абстрактный интерфейс и не знало вообще, с чем оно работает, с БД, или еще каким-нибудь источником данных. Тут можно свапнуть БД на другую (например в тестах использовать sqlite вместо постгреса или вообще какой-нибудь nosql). Я еще в одном проекте видел такое — каждый row в результатах запроса конвертировался в boost.property_tree, который передавался кругом. Все ф-ии работающие с данными принимали property_tree, все довольно универсально и гибко было, скажем коду было не важно, пришел property_tree из базы или из POST запроса. Накладные расходы конечно большие, но это сильно лучше чем размазывать работу с БД по всему приложению и при каждом изменении схемы переписывать код и пересобирать.
И что ты понимаешь под фильтрациями? Where statement в SQL или обработку результатов запроса?