SQL-запросы в виде констант

[magic]

SQL-запросы в виде констант

Всем привет.

Во время разбора одного скрипта, заметил следующую конструкцию. Все SQL запросы сделаны в виде констант и вынесены в отдельный файл:

define('SQL_SELECT_USER_MESSAGES', 'SELECT forum_id, user_id, message_id FROM '.TABLE_MESSAGES.' WHERE user_id = ?');

Кто-нибудь может обьяснить смысл сего действа?

 

[StUV]

Кто-нибудь может обьяснить смысл сего действа?

для поддержки разных субд
для проектов с несложной логикой данных вполне катит
+
запросы может править бд-шник, не вдаваясь в логику их использования в пхп-коде

 

[Wicked]

magic
тебя, случаем, не вопросительный знак там смущает?

 

[magic]

Про вопросительный знак смешно Мне интересно, какие преимущества и недостатки такого метода.

 

[TutanXamoN]

При грамотной реализации преимущества есть. Случай из жизни: разрабатывалась CRM-ка. Данные о клиентах забиваються в таблицу `customer` но на момент создания таблицы она стала `cutomer` мелочь но неприятно и в таком виде здавать никто не будет. Так вот в таком случае отдельный файл с строчкой вида :

$customer_table='`customer`'

избавил от достаточно большого гемора - БДшник существо владеющее англ. на примитивном уровне ему что `customer` что `cutomer` абы данные доставать да пихать а учитывая кол-во запросов к етой таблице (минимум 3-5 в каждом скрипте) вручную всё править трудоёмко.

Или другой вариант нужно прикрутить какую-то системку на уже существующий сайт. Часто хостеры ставят для маленьких пакетов ограничение в одну создаваемую базу - что будет делать человек если для интеграции системы в базе должна быть таблица `orders ` а унас она есть и нужна для других целей?

 

[Фанат]

TutanXamoN, мне кажется, ты не понял вопроса

 

[magic]

Автор оригинала: StUV
для поддержки разных субд

Вынесение запросов в отдельный файл для поддержки разных БД? Спорный вопрос, так как для этого есть другие методы.

для проектов с несложной логикой данных вполне катит

Где могут быть камни для сложной логики?

запросы может править бд-шник, не вдаваясь в логику их использования в пхп-коде

Здесь согласен. Наверное, еще и запросы проще тестировать.

Автор оригинала: TutanXamoN

$customer_table='`customer`'

...
в базе должна быть таблица `orders ` а унас она есть и нужна для других целей?

Это решается использованием констант для префикса и названий таблиц.

В данный момент речь идет о целесообразности вынесения всех SQL-запросов в отдельный файл(ы).

 

[TutanXamoN]

Вопрос понял.
Преимущества
1. в больших проектах для минимализации времени требуемого на переработки
2. почему-то вынос часто ипсользуемого кода в функции и запихивание их в отдельный файл не вызывает вопросов здесь аналогично.
Недостатки
1. никто нормально таким вариантом не пользуеться. всё-равно найдётся человек уклепавший пару запросов напрямую и будет небольшой геморой.

 

[korchasa]

Автор оригинала: magic
Про вопросительный знак смешно Мне интересно, какие преимущества и недостатки такого метода.

Недостатки будут проявляться, когда придется править два файла, при изменении отдаваемого в пых набора данных. Плюс на больших проектах этот файл будет не хилых размеров, со всеми вытекающими. Наблюдал еще ситуации, когда путались похожие идентификаторы (там правда не запросы были).

 

[Фанат]

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

 

[korchasa]

Автор оригинала: TutanXamoN
2. почему-то вынос часто ипсользуемого кода в функции и запихивание их в отдельный файл не вызывает вопросов здесь аналогично.

Данные неразрывно связаны с кодом, части алгоритма же должны быть быть независимыми для реюза, тестирования, бла-бла-бла...

 

[Фанат]

korchasa
ну, это слабый довод. то же самое можно сказать про разделение кода и шаблонов.

 

[fixxxer]

так удобнее просто.
чисто визуально.
сам так делаю, только конечно не define а class const и не все в кучу а в классе который собственно запрос использует.

 

[korchasa]

Автор оригинала: *****
korchasa
ну, это слабый довод. то же самое можно сказать про разделение кода и шаблонов.

Вынесение HTML'я вынужденная мера -- его слишком много, и читать лапшу из-за этого трудно.
Например, генерация XML -- пока его куски небольшие, мало кто выносит его куда-то, а уж тем более использует шаблонизатор.

 

[Фанат]

тьфу.
шаблон - это всегда лапша.
как вы вообще можете участвовать в дискуссиях, не понимая бессмысленности своих доводов?
все, что ты сказал про запросы, можно сказать и про шаблоны. и наоборот.

 

[magic]

Автор оригинала: fixxxer
сам так делаю, только конечно не define а class const и не все в кучу а в классе который собственно запрос использует.

Это уже апгрейд метода
Бывали проблемы с большим количеством запросов или у тебя отдельный клас запросов для каждой задачи? Можешь показать пример кода?

 

[fixxxer]

отдельный класс для каждой сущности модели, типа "пользователь", "продукт" и т.п.

пример не покажу, лень делать короткий пример

 

[FractalizeR]

Автор оригинала: fixxxer
отдельный класс для каждой сущности модели, типа "пользователь", "продукт" и т.п.

пример не покажу, лень делать короткий пример

Не думаю, чтобы он оказался коротким Метод моделирования предметной области целесообразно использовать только на больших проектах. На маленьких он будет тормозить разработку (у меня сейчас похожая ситуация). Хотя, если планируется рост или частые доработки этого маленького проекта, в конечном итоге использование такого подхода оправдано.

 

[atv]

В данный момент речь идет о целесообразности вынесения всех SQL-запросов в отдельный файл(ы).

Я думаю не стоит на этом заморачиваться. Это как вопрос о файловой структуре проекта - какая лучше всего. В какой то момент хороша одна, потом, со временем, реорганизуеш в другую.

 

[korchasa]

Автор оригинала: *****
все, что ты сказал про запросы, можно сказать и про шаблоны. и наоборот.

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