SQL файлы в проекте
От: s.kluchnikov  
Дата: 06.09.19 19:39
Оценка:
Добрый день, подскажите как хранить тексты SQL запросов в проекте.
Нужно в результате компиляции программы тексты должны быть не доступны для просмотра.
Re: SQL файлы в проекте
От: alex_mah Россия www.elsy.ru
Дата: 06.09.19 20:05
Оценка: 15 (1) +3
Здравствуйте, s.kluchnikov, Вы писали:

SK>Добрый день, подскажите как хранить тексты SQL запросов в проекте.

SK>Нужно в результате компиляции программы тексты должны быть не доступны для просмотра.

Хранить запросы, которые не хочешь показывать посторонним глазам, нужно в виде закриптованных хранимых процедур. И сервер БД использовать тот, который это поддерживает.

И то, это не даёт гарантии, что их не увидят.

Во всех остальных случаях твои запросы выковыриваются на раз каким-нибудь профайлером.
Re[2]: SQL файлы в проекте
От: Mystic Artifact  
Дата: 06.09.19 22:27
Оценка:
Здравствуйте, alex_mah, Вы писали:

_>Во всех остальных случаях твои запросы выковыриваются на раз каким-нибудь профайлером.

Не каким-нибудь, а штатным (если конечно в данном случае такой есть).
Re: SQL файлы в проекте
От: Mystic Artifact  
Дата: 06.09.19 22:28
Оценка: +1
Здравствуйте, s.kluchnikov, Вы писали:

SK>Добрый день, подскажите как хранить тексты SQL запросов в проекте.

SK>Нужно в результате компиляции программы тексты должны быть не доступны для просмотра.

Вообще, а в чем секрет? Какую задачу пытаешься решить? От кого спрятать запросы?
Re: SQL файлы в проекте
От: GarryIV  
Дата: 07.09.19 07:07
Оценка:
Здравствуйте, s.kluchnikov, Вы писали:

SK>Добрый день, подскажите как хранить тексты SQL запросов в проекте.

SK>Нужно в результате компиляции программы тексты должны быть не доступны для просмотра.

До какого только маразма люди не доходят... Вот нафига? Вы тас секреты хардкодите?
Да храните как угодно, шифруйте бинарники только.
Ну или хранимки, как уже советовали, хотя хз может у вас и имена хранимых процедур тоже секрет...
WBR, Igor Evgrafov
Re[2]: SQL файлы в проекте
От: s.kluchnikov  
Дата: 07.09.19 09:44
Оценка:
Здравствуйте, Mystic Artifact, Вы писали:

MA>Здравствуйте, s.kluchnikov, Вы писали:


SK>>Добрый день, подскажите как хранить тексты SQL запросов в проекте.

SK>>Нужно в результате компиляции программы тексты должны быть не доступны для просмотра.

MA> Вообще, а в чем секрет? Какую задачу пытаешься решить? От кого спрятать запросы?



Ранее хранил в ввиде сторок:

namespace HelpersSQL
{
    public static class SQL_product
    {
        public static string sql_select_product = "select * from product";
    }
}


или в виде текстовых файлов (которые лежали рядом с exe файлом программы).

Вариант с строками из кода не удобен (большие запросы бывают и читабельность теряется).
Вариант с внешними текстовыми файлами не удобен (лишние файлы + так наверное не делают).
Re[3]: SQL файлы в проекте
От: takTak  
Дата: 07.09.19 10:11
Оценка:
берёшь что-то типа EF Code First или SQL Server Database Project, используешь обфускатор и в путь!

ну или сам пишешь что-то ручками, что дешифрует sql файлы, которые ты поставляешь вместе с проектом или в качестве ресурса, ключ для дешифровки хранится где-то в каком-то стороннем сервисе или ещё где, например, в той же самой базе данных
Отредактировано 07.09.2019 10:17 takTak . Предыдущая версия .
Re[4]: SQL файлы в проекте
От: s.kluchnikov  
Дата: 07.09.19 10:23
Оценка:
Здравствуйте, takTak, Вы писали:

T>берёшь что-то типа EF Code First или SQL Server Database Project, используешь обфускатор и в путь!


Спасибо, но дело не в обустификации или коммерческой тайне.

Дело только в хранении в проекте.
Хранить sql запросы в виде строк, внешних файлов или ресурсов.

Как делают коллеги в своих проектах?
Re[5]: SQL файлы в проекте
От: takTak  
Дата: 07.09.19 10:34
Оценка:
T>>берёшь что-то типа EF Code First или SQL Server Database Project, используешь обфускатор и в путь!

SK>Спасибо, но дело не в обустификации или коммерческой тайне.


SK>Дело только в хранении в проекте.

SK>Хранить sql запросы в виде строк, внешних файлов или ресурсов.

SK>Как делают коллеги в своих проектах?


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

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

короче, речь идёт о database/schema migration ?
Отредактировано 07.09.2019 10:37 takTak . Предыдущая версия .
Re[5]: SQL файлы в проекте
От: Mystic Artifact  
Дата: 07.09.19 16:35
Оценка: +1
Здравствуйте, s.kluchnikov, Вы писали:

SK>Спасибо, но дело не в обустификации или коммерческой тайне.

Это как-то диссонирует, с изначальным вопросом. Файлы рядом вполне можно помещать в ресурсах, это довольно просто. Их можно шифровать. Вместо шифрования ручками, можно заставить это делать какие-нибудь обфускаторы. Если вопрос просто избавиться от шаловливых пользовательских ручек (которые могут бегать и изменять файлы лежащие рядом) — то нешифрованных ресурсов более чем достаточно, т.к. все остальные действия не устоят перед целенаправленным воздействием.

SK>Дело только в хранении в проекте.

SK>Хранить sql запросы в виде строк, внешних файлов или ресурсов.
SK>Как делают коллеги в своих проектах?
С "сырыми" SQL запросами, стараются не работать вообще. Есть конечно исключения, но они должны быть как-то обоснованы.

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

Во-вторых, хранимые процедуры: особенно если это MSSQL — то database project отличная вещь, т.к. избавляет от кучи рутины, и проверяет скрипты на ошибки и предоставляет набор инструментов для деплоя бд. Раньше этого сильно не хватало.

Я работал в крупном проекте, где всё было на хранимках, и это было достаточно удобно, тем более, была культура оформления SQL кода. При этом, деплой клиентских приложений случался реже, чем правки БД (впрочем, это последствие того, что в БД вся логика). Наличие процедур так же очень помогало при сопровождении, потому, что за некоторыми "стандартными" вьюхами пряталась логика, которая основательно менялась сквозь года. Сейчас, предпочитаю LINQ, но и архитектура нынешних приложений весьма отличается, а те запросы которые я делаю (динамические), я бы никакими наколеночными конструкторами бы не построил, хотя раньше и приходилось строить руками. В одном "соседнем" проекте есть ключевой генератор запросов, на основе склейки строк, его надо бы и переделать, но это уже такой монолит, что никто не знает как подойти, в лоб на линке ничего не выйдет... А переделать надо — оно безбожно тормозит (правда начинать надо с БД — на всех инсталляциях даже в индексах зоопарк ).

Поэтому на мой вкус — я бы никогда в жизни не согласился бы хардкодить запросы ни в коде, ни в ресурсах, нигде.
Re[6]: SQL файлы в проекте
От: s.kluchnikov  
Дата: 07.09.19 22:31
Оценка:
Mystic Artifact, спасибо!
Re: SQL файлы в проекте
От: Shmj Ниоткуда  
Дата: 08.09.19 03:46
Оценка: +2 -3 :)
Здравствуйте, s.kluchnikov, Вы писали:

SK>Добрый день, подскажите как хранить тексты SQL запросов в проекте.

SK>Нужно в результате компиляции программы тексты должны быть не доступны для просмотра.

Уже никто не пишет тексты запросов руками — используется ORM типа Entity Framework. Малая часть запросов, которые не покрывают возможности ORM, хранится прямо в коде.
MS делают видео вместо статей - где разум?
От: Kolesiki  
Дата: 08.09.19 09:42
Оценка:
Здравствуйте, s.kluchnikov, Вы писали:

SK>Ранее хранил в ввиде сторок:

SK> public static string sql_select_product = "select * from product";

Вот это зачем?? Что, "sql_select_product" настолько часто переиспользуется?

SK>Вариант с строками из кода не удобен (большие запросы бывают и читабельность теряется).


Большой запрос — объективная необходимость, он не станет меньше, если его вынести во внешний файл — разве что гемора прибавится.
Читабельность — какая конкретно?
Обычно пишу прямо в вербатим строках:

    var sql = @"
SELECT * FROM Person
";


Проблем с чтением никаких. А если б в MS работали люди с интеллектом, то и подсветку SQL увидели бы (как в Nemerle).
Отредактировано 08.09.2019 9:43 Kolesiki . Предыдущая версия .
Re[6]: MS делают видео вместо статей - где разум?
От: Kolesiki  
Дата: 08.09.19 10:06
Оценка: -3 :)
Здравствуйте, Mystic Artifact, Вы писали:

MA> С "сырыми" SQL запросами, стараются не работать вообще. Есть конечно исключения, но они должны быть как-то обоснованы.


Обоснование элементарно: SQL — это свой особый язык. Его логика вообще никак не пересекается с ЯОН. Кроме того, код — его задача не просто вывернуться и сделать "красиво", а сделать код СОПРОВОЖДАЕМЫМ. Это первое и главное условие коммерческого проекта. Поэтому сгенерил в коде конекшн, передал строку-запрос, получил данные — всё, молодец. Такой код понимаем любым джуном, кто читал хотя бы одну статью по СУБД.

MA> Во-первых, есть LINQ, который покрывает большую часть потребностей


Этот уродец — плод скрещения ужа с ежом. Мало того, что не все и сам SQL хорошо понимают, а тут ещё предлагают его же, но с вывернутым наизнанку синтаксисом "от M$". Оно нам надо?? Есть 40-летний стандарт SQL. Его изучают всегда и везде. Встретив "чистый" SQL в коде, никто не будет париться с пониманием. В отличии от LINQ.

MA>, а в сфере построения динамических запросов он незаменим.


Ерунда. Делал такие же динамические запросы тупо на составной строке запроса. По структуре логики — 1:1 с динам.запросом. Зато на стандартном SQL.

MA> Во-вторых, хранимые процедуры: особенно если это MSSQL — то database project отличная вещь


Имею категорически противоположный опыт. Мне достаточно иметь в проекте SQL и C#. Зачем мне ещё и ТРЕТИЙ язык?! Больше загрузить мозги нечем? Кстати, что за язык? T-SQL? Вот жалость... а я учил PL/SQL! А Васян — вообще PHP в сервер внедрил. А третий человек, которого потом наймут для поддержки, вообще хранимки не видал. И таких людей куда больше, чем "профессионалов по разбрасыванию кусков логики по проекту". Знаете, жуйте сами свои хранимки! Это на порядок больший геморой + нулевая сопровождаемость и понимаемость кода.

Хранимки — пережиток 80-ых, когда логика была нужна, а где её писать — не знали, потому и засунули на сервер. С "изобретением" application server все эти "потуги на хранимках" — заплесневелый неуклюжий атавизм.

MA> Поэтому на мой вкус — я бы никогда в жизни не согласился бы хардкодить запросы ни в коде, ни в ресурсах, нигде.


"Каждый сам кузнец своих грабель!". С трудом понимаю только одно — зачем ковать грабли и кидать себе на дорогу, когда можно обойтись без них.
Re[7]: MS делают видео вместо статей - где разум?
От: Mystic Artifact  
Дата: 08.09.19 10:41
Оценка: +3
Здравствуйте, Kolesiki, Вы писали:

K>Обоснование элементарно: SQL — это свой особый язык. Его логика вообще никак не пересекается с ЯОН. Кроме того, код — его задача не просто вывернуться и сделать "красиво", а сделать код СОПРОВОЖДАЕМЫМ. Это первое и главное условие коммерческого проекта. Поэтому сгенерил в коде конекшн, передал строку-запрос, получил данные — всё, молодец. Такой код понимаем любым джуном, кто читал хотя бы одну статью по СУБД.

Это не обоснование, а твои выдумки, с хипстерщиной перемешанной с вкусовщиной.

MA>> Во-первых, есть LINQ, который покрывает большую часть потребностей

K>Этот уродец — плод скрещения ужа с ежом. Мало того, что не все и сам SQL хорошо понимают, а тут ещё предлагают его же, но с вывернутым наизнанку синтаксисом "от M$". Оно нам надо?? Есть 40-летний стандарт SQL. Его изучают всегда и везде. Встретив "чистый" SQL в коде, никто не будет париться с пониманием. В отличии от LINQ.
Мне надо. А неподдерживаемые вкорычки в виде любых строк мне лично — не надо. Я тебе намекну — нет стандарта даже на запись и передачу параметров. Или ты клеишь строки? Привет иньекции? Джуны твои тоже клейкой строк занимаются?

MA>>, а в сфере построения динамических запросов он незаменим.

K>Ерунда. Делал такие же динамические запросы тупо на составной строке запроса. По структуре логики — 1:1 с динам.запросом. Зато на стандартном SQL.
Честно, иди мимо, нихера ты не делал. Динамический запрос != фильтр, иначе ни о какой "составной строке запроса" не идет и речи. Билдеры давно использовались, но с LINQ это делать намного продуктивнее. В общем, клей строки дальше — так тоже можно.

MA>> Во-вторых, хранимые процедуры: особенно если это MSSQL — то database project отличная вещь

K>Имею категорически противоположный опыт. Мне достаточно иметь в проекте SQL и C#. Зачем мне ещё и ТРЕТИЙ язык?! Больше загрузить мозги нечем? Кстати, что за язык? T-SQL? Вот жалость... а я учил PL/SQL! А Васян — вообще PHP в сервер внедрил. А третий человек, которого потом наймут для поддержки, вообще хранимки не видал. И таких людей куда больше, чем "профессионалов по разбрасыванию кусков логики по проекту". Знаете, жуйте сами свои хранимки! Это на порядок больший геморой + нулевая сопровождаемость и понимаемость кода.
Какой ещё третий язык? Это все тот же SQL, понимаемый сервером. Если ты не осилил SSDT, он же "database project" — то это твоя проблема, незачем вводить в заблуждение других людей рассказывая сказки.

K>Хранимки — пережиток 80-ых, когда логика была нужна, а где её писать — не знали, потому и засунули на сервер. С "изобретением" application server все эти "потуги на хранимках" — заплесневелый неуклюжий атавизм.

Эти "потуги" на хранимках отлично справляются со своими задачами. Через 40 лет их не сделали легаси, наоборот к ним прикрутили нативную кодогенерацию. Если ты не видишь их преимущества — то видимо надо курить вопрос далее.

MA>> Поэтому на мой вкус — я бы никогда в жизни не согласился бы хардкодить запросы ни в коде, ни в ресурсах, нигде.

K>"Каждый сам кузнец своих грабель!". С трудом понимаю только одно — зачем ковать грабли и кидать себе на дорогу, когда можно обойтись без них.
Вот именно.
Re: MyBatis.NET
От: igor-booch Россия  
Дата: 09.09.19 12:08
Оценка:
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[2]: SQL файлы в проекте
От: _ABC_  
Дата: 09.09.19 23:06
Оценка: +2
Здравствуйте, Shmj, Вы писали:

S>Уже никто не пишет тексты запросов руками — используется ORM типа Entity Framework. Малая часть запросов, которые не покрывают возможности ORM, хранится прямо в коде.

Странно. Я пишу, например. И точно знаю, что куча других тоже.
Re[7]: MS делают видео вместо статей - где разум?
От: _ABC_  
Дата: 09.09.19 23:56
Оценка: +5
Здравствуйте, Kolesiki, Вы писали:

K>Этот уродец — плод скрещения ужа с ежом. Мало того, что не все и сам SQL хорошо понимают

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

K>Есть 40-летний стандарт SQL. Его изучают всегда и везде.

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

K>Встретив "чистый" SQL в коде, никто не будет париться с пониманием. В отличии от LINQ.

Я, работающий с SQL и СУБД, парюсь с пониманием SQL, втречаясь с ним в коде другого языка. Особенно, если это склейка динамического SQL.
LINQ проще.

K>Ерунда. Делал такие же динамические запросы тупо на составной строке запроса. По структуре логики — 1:1 с динам.запросом. Зато на стандартном SQL.

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

K>Имею категорически противоположный опыт. Мне достаточно иметь в проекте SQL и C#.

Define SQL. Потому, что хранимки — это часть стандарта SQL, например.

K>Хранимки — пережиток 80-ых, когда логика была нужна, а где её писать — не знали, потому и засунули на сервер.

Именно поэтому хранимки и куча всего, что делало их возможным, не были в стандарте SQL вплоть 1996-го, когда выпустили расширение 92-го стандарта?
Re: SQL файлы в проекте
От: white_znake  
Дата: 13.09.19 10:02
Оценка:
Здравствуйте, s.kluchnikov, Вы писали:

SK>Добрый день, подскажите как хранить тексты SQL запросов в проекте.

SK>Нужно в результате компиляции программы тексты должны быть не доступны для просмотра.

Хранение SQL запросов в виде текста не очень хорошее решение, потому что:
1. Возможны SQL инъекции
2. Тратиться ресурсы на подстановку параметров в строки, склеивание строк.
3. Запрос ни как не оптимизируется.

Лучше использовать ORM для легких запросов и хранимые процедуры для средних и тяжелых запросов.

Но хранить DDL операции для миграции бд как текстовые файлы — нормальное решение.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.