Здравствуйте, Лекс, Вы писали:
Л>Всем привет! Л>У меня проект работает с БД. Для удобства, все запросы вынесены в один хедер:
Удобство, имхо, довольно сомнительное. Уже давно есть Stored Procedures.
Л>К проекту мона добавить файлы *.sql. А как их использовать? Парсить или есть более простые варианты?
Это, грубо говоря, скрипты создания/модификации/удаления бд/таблиц и наполнения их данными. Погуглите по поводу isql, osql (в случае MSSQL).
HgLab: Mercurial Server and Repository Management for Windows
Н>Удобство, имхо, довольно сомнительное. Уже давно есть Stored Procedures.
Поясню:
Конечно с предложенным вариантом MS SQL — мои дефайны сомнительны.
А как быть с Access'ом или текстовиком?
Меня интересует один вопрос, как проще использовать *.sql в проекте — дефайны выгледят "не очень", но если их для читабельности приукрасить, скажем:
#define A \
"SELECT m.Field1 \n\
m.Field2 \n\
m.Field3 \n\
a.Field1 \n\
FROM Tab1 AS m \n\
LEFT OUTER JOIN Tab2 AS a \n\
ON m.Field3 = a.Field1 \n\
WHERE a.Field1 = %s "
CString str;
str.Format(_T(A), (int)5);
Так вот с таким форматированием легко набрать 2000 символов и более, а проект в UNICODE (типа ограничтесь товарищь програмист 1024 символами).
Здравствуйте, Лекс, Вы писали:
Л>Поясню: Л>Конечно с предложенным вариантом MS SQL — мои дефайны сомнительны. Л>А как быть с Access'ом или текстовиком?
Затык образовался какой-то. У вас есть скрипты SQL (из чего я предполагаю, что вы используете полнофункциональную RDBMS), но использовать SP вы не можете по причине Access'а или текстовика, и само по себе это сочетание странно.
Л>Меня интересует один вопрос, как проще использовать *.sql в проекте — дефайны выгледят "не очень"
А вот уже идеологический вопрос. Можно свалить все дефайны в кучу и наслаждаться длительными компиляциями при изменении какого-то одного малюсенького запроса. Удобство есть, но какое-то сомнительное. А можно развести все запросы по классам DAL'а и быстренько компоновать объектные файлы. Однако в этом случае все запросы будут ровным слоем размазаны по куче классов. Хотя если взглянуть на это с ООПизированной точки зрения, то можно найти некоторую выгоду.
А *.sql как таковые использовать вряд ли возможно.
Л>Так вот с таким форматированием легко набрать 2000 символов и более, а проект в UNICODE (типа ограничтесь товарищь програмист 1024 символами).
Я про ограничение на #define не нашел ничего.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Нахлобуч, Вы писали:
Н>Затык образовался какой-то. У вас есть скрипты SQL (из чего я предполагаю, что вы используете полнофункциональную RDBMS), но использовать SP вы не можете по причине Access'а или текстовика, и само по себе это сочетание странно.
Это конечно не сочетание , это "к примеру"
Л>>Так вот с таким форматированием легко набрать 2000 символов и более, а проект в UNICODE (типа ограничтесь товарищь програмист 1024 символами).
Н>Я про ограничение на #define не нашел ничего.
Я тоже был удивлен. Вот что говорит VC 7.1:
Compiler Error C2026:
The string was longer than the limit of 2048 single-byte characters.
Prior to adjacent strings being concatenated, a string cannot be longer than 2048 single-byte characters.
A Unicode string of about one half this length would also generate this error.
Здравствуйте, Лекс, Вы писали:
Л>Здравствуйте, Нахлобуч, Вы писали:
Л>>>Так вот с таким форматированием легко набрать 2000 символов и более, а проект в UNICODE (типа ограничтесь товарищь програмист 1024 символами).
в ресурсы запихать и грузить в рантайме по ID ресурса
только вот нафига все это не пойму.. есть же хранимые процедуры
и инкапсуляция опять же
например понадобится вам оптимизация SQL по производительности — не
нужно перекомпилять код программы если весь SQL сидит в SP
A>только вот нафига все это не пойму.. есть же хранимые процедуры A>и инкапсуляция опять же A>например понадобится вам оптимизация SQL по производительности — не A>нужно перекомпилять код программы если весь SQL сидит в SP
зачем? вы проектируете систему "независимую от СУБД"?
1.таких систем по опыту обычно не бывает — выбор СУБД закладывается на этапе проектирования,
т.к. от этого зависит многое другое — выбор ОС, железа и т.д.
2. если уж очень хочется — можно выделить это в отдельный слой архитектуры (data access layer)
A>зачем? вы проектируете систему "независимую от СУБД"?
Я написал то, на что ты не обратил внимание в посте автора.
А твой ответ больше подходит на : "Да беспорно есть такие животные как собаки, но у них ведь есть глисты!!! Вот про них я сейчас вам и расскажу!"
Здравствуйте, Лекс, Вы писали:
Л>Здравствуйте, Нахлобуч, Вы писали:
Н>>Удобство, имхо, довольно сомнительное. Уже давно есть Stored Procedures.
Л>Поясню: Л>Конечно с предложенным вариантом MS SQL — мои дефайны сомнительны. Л>А как быть с Access'ом или текстовиком?
Л>Меня интересует один вопрос, как проще использовать *.sql в проекте — дефайны выгледят "не очень", но если их для читабельности приукрасить, скажем: Л>
Л>#define A \
Л> "SELECT m.Field1 \n\
Л> m.Field2 \n\
Л> m.Field3 \n\
Л> a.Field1 \n\
Л> FROM Tab1 AS m \n\
Л> LEFT OUTER JOIN Tab2 AS a \n\
Л> ON m.Field3 = a.Field1 \n\
Л> WHERE a.Field1 = %s "
Л>CString str;
Л>str.Format(_T(A), (int)5);
Л>
Л>Так вот с таким форматированием легко набрать 2000 символов и более, а проект в UNICODE (типа ограничтесь товарищь програмист 1024 символами).
вариант из MSDN —
Вместо длинных #define A используй
char A[] = "SELECT m.Field1 \n"
"m.Field2 \n"
"m.Field3 \n"
"a.Field1 \n"
"FROM Tab1 AS m \n"
"LEFT OUTER JOIN Tab2 AS a \n"
"ON m.Field3 = a.Field1 \n"
"WHERE a.Field1 = %s";
, это "к примеру"
