Разделение кода по работе с БД от остального кода «движка» CMS

[scorpion-ds]

Разделение кода по работе с БД от остального кода «движка» CMS

В общем, суть такая, ставится вопрос по разработке новой версии CMS и одно из требований возможность использование различный БД (MySQL, MSSQL, …), а также улучшение безопасности.

Я предложил вариант не использовать в коде движка вообще SQL запросов, а вынести их в отдельный файл(ы), то есть создать что-то вроде SQL-шаблонов, а по необходимости вызывать различные шаблоны, в некоторых случаях, на мой взгляд, можно использовать универсальные функции, к примеру, при запросе INSERT, в функцию передавать имя таблицы, и массив, где ключи соответствуют полям в таблицы, а значения массива значениям в базе.
В результате получим некий вариант драйвера для работы с БД и если все правильно спланировать универсальность при работе с различными БД.

Насколько такой подход правильный при организации работы движка с базой данных?

P.S.: извиняюсь может за ламерский вопрос, но гугле найти ни чего не смог, наверно неправильно спрашивал.

 

[Фанат]

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

ИМХО, одна из самых дурных идей, которые приходят в голову разработчикам - это идея "использовать разные СУБД". В итоге получается написано в 4 раза больше кода, чем для одной.

 

[флоппик]

Все таки, в таких случаях «дурных идей» лучше абстрагировать проверенными методами - например, написать(взять готовый) минимальный ОРМ.

 

[Фанат]

флоппик
А орм бывает минимальным?

 

[флоппик]

Нет, но минимальной бывает реализация. Я сам по себе противник абстракций от БД, вообще-то, поэтому предпочту не учавствовать в данной дискуссии.

 

[zerkms]

следует помнить, что создавая подобные требования ты обрекаешь продукт на неиспользование фич конкретной СУБД. и в итоге у тебя остаются ANSI SQL-type примитивные запросы (единственные, которые хоть с какой-то гарантией будут работать везде и одинаково).
совершенно непонятно, в чём тогда разница в СУБД вообще, если использовать возможности каждой из них на уровне ANSI и забывая конкретные расширения sql?

 

[scorpion-ds]

Автор оригинала: *****
Ну, если не жалко времени на переписывание половины кода, то правильный.
Хотя на мой взгляд, веб-приложение только с базой и работает. То есть, при использовани шаблонов так и получится, что шаблоны останутся, а весь код приложения будет переписываться.

ИМХО, одна из самых дурных идей, которые приходят в голову разработчикам - это идея "использовать разные СУБД". В итоге получается написано в 4 раза больше кода, чем для одной.

Ну пока идет обсуждение только, еще точно ни чего не известно. В первой версии системы, которая была придумана в 2006 году все было вперемешку, разве что шаблоны вынесены отдельно, но, к примеру, была большая проблема поиска возможных SQL- инъекций, если все это вынести в «отельный файл» по идеи решатся это будет проще.

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

 

[Фанат]

была большая проблема поиска возможных SQL- инъекций

а их и не надо искать. никаких инъекций в природе не бывает. надо грамотно составлять запросы.

И вообще, при чем здесь "отдельный файл"? Что конкретно там будет "проще"?

почему в MySQL так мало используются триггеры

потому что появились совсем недавно

Я бы хотел их начать применять.

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

 

[scorpion-ds]

Автор оригинала: zerkms
следует помнить, что создавая подобные требования ты обрекаешь продукт на неиспользование фич конкретной СУБД. и в итоге у тебя остаются ANSI SQL-type примитивные запросы (единственные, которые хоть с какой-то гарантией будут работать везде и одинаково).
совершенно непонятно, в чём тогда разница в СУБД вообще, если использовать возможности каждой из них на уровне ANSI и забывая конкретные расширения sql?

Но по идее, если все запросы будут располагаться в отдельном «файле», то подкручивание под конкретную БД будет проще, хотя возможно мы что-то и потерям от универсальности.

 

[флоппик]

дада... $db->execSQLById(SQL_32656);

 

[scorpion-ds]

Автор оригинала: флоппик
дада... $db->execSQLById(SQL_32656);

типа того, кстати в движке форума IPB так примерно и есть.

 

[zerkms]

Но по идеи, если все запросы будут располагаться в отдельном «файле», то подкручивание под конкретную БД будет проще, хотя возможно мы что-то и потерям от универсальности.

этого мало. разные субд будут предлагать разные возможности. так что то, что в одной субд делается 10 запросами, в другой будет выполняться с помощью 1. в итоге и весь код "обвязки" запросов тоже будет другим.

 

[tf]

а что насчет ->select()->from()->table()
и подобные генерации, совсме не помю как это называется, но хочется себе для админки сделать

 

[scorpion-ds]

Автор оригинала: tf
а что насчет ->select()->from()->table()

Не очень понимаю как это организовать можно ...

 

[С.]

Пишется АПИ библиотека для данного конкретного приложения:

GetItem()
SetItem()
GetListOfItems()
и т.п.

Подмена библиотеки под другую базу не составит большого труда.

 

[nerezus]

Zend_Db

 

[scorpion-ds]

Автор оригинала: nerezus
Zend_Db

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