>... сырым sql СУБД
LINQ лучше прожарен, чем SQL? Почему?

Здравствуйте, Олег К., Вы писали:

ОК>Ну так ты начни писать еще в стиле Си — откажись от функций членов и сделай все переменные члены публичными. Тебе ж положить на философию большой болт.

По-моему, всё в точности наоборот. Мне положить на философию, поэтому я могу выбирать самые современные инструменты. Ты со своей философией застрял даже не в стиле Си, а в T-SQL в стиле флажкового программирования.

Здравствуйте, Олег К., Вы писали:

ОК>Ну так ты и завяжи со своей философией, что в базе не должно быть бизнес логики. А то как-то однобоко получается. Есть твоя философия, которой следует придерживаться, а есть моя философия с которой следует завязать.
ОК>Заодно еще откажись от инкапсуляции в Си шарповом коде. Сделай все переменные члены публичными и откажись от функций членов!

Да уже. Это какой-то фиерический пипец. В огороде бузина, а в Киеве дядька

Здравствуйте, Alexander Polyakov, Вы писали:

>>... сырым sql СУБД
AP>LINQ лучше прожарен, чем SQL? Почему?

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

Здравствуйте, koodeer, Вы писали:

K>Хотел философию? Получай!

Не трать патроны. У чувака тяжёлый вывих головного мозга. Тут не убеждать, тут лечить надо.

IT>>>На философию мне положить большой болт. Это самое последнее о чём нужно думать. Есть более важные вещи, такие как поддержка кода и организация рабочего процесса
ОК>>Ну так ты начни писать еще в стиле Си — откажись от функций членов и сделай все переменные члены публичными. Тебе ж положить на философию большой болт.
S>Подозреваю, если для решения некоторой конкретной задачи программирование в процедурном стиле (в стиле Си, как ты пишешь) без инкапсуляции, приватных методов и свойств позволит создать более компактный, выразительный, легко читаемый, тестируемый и поддерживаемый код, то Игорь без колебаний махнет рукой на все фенечки ООП. Для HelloWord или вычисления корней квадратного уравнения ты же станешь приватные методы писать правда (я утрирую конечно)?

Не стану.

S>Другой вопрос — даст ли переход на Си-стиль какой-нибудь профит?
S>А вот от отказа от DAL Игорь, очевидно, профит получает.

При чем тут ДАЛ? Ты вообще понял о чем речь? База открыта, а ты мне тут про ДАЛ.

Ну и коли ты решил выступить его адвокатом, тогда объясни почему он выборочно так поступает? Дальше, объясни почему он впадает в истерику на справедливое, в принципе, замечание?

S>Твой же пуристический подход предполагает следование догмам независимо от того нужны ли они и продуктивны ли.

Это не так. Даже на сиквеле можно писать понятный и поддерживаемый код. Другое дело, что большинство не умеет. Соответсвенно у большинства будет код на Си шарпе не лучше кода на сиквеле.

ОК>>Ну так ты начни писать еще в стиле Си — откажись от функций членов и сделай все переменные члены публичными. Тебе ж положить на философию большой болт.

IT>По-моему, всё в точности наоборот. Мне положить на философию, поэтому я могу выбирать самые современные инструменты. Ты со своей философией застрял даже не в стиле Си, а в T-SQL в стиле флажкового программирования.

Ты дальше своей Вижуал Студии ничего и не видешь.

K>>Хотел философию? Получай!

IT>Не трать патроны. У чувака тяжёлый вывих головного мозга. Тут не убеждать, тут лечить надо.

Аналогично я могу сказать и про тебя.

ОК>>Ну так ты и завяжи со своей философией, что в базе не должно быть бизнес логики. А то как-то однобоко получается. Есть твоя философия, которой следует придерживаться, а есть моя философия с которой следует завязать.
ОК>>Заодно еще откажись от инкапсуляции в Си шарповом коде. Сделай все переменные члены публичными и откажись от функций членов!

IT>Да уже. Это какой-то фиерический пипец. В огороде бузина, а в Киеве дядька

Еще бы! По делу сказать ничего не можешь. Вместо этого ты устроил тут истерику на справедливое, в принципе, замечание.

Нравится тебе твой подход — пользуйся! Но того, что там есть фундаментальная проблема не отнять. И ты ведь даже не задумывался об этом до этого поста!

A>>А в случае нормализации\денормализации много кода на C# переписать придется? Маппинг таблиц на классы в linq2db достаточно гибок, чтобы изолировать от этих изменений?

MC>Мы в текущем проекте с linq2db массируем и жонглируем таблицами и колонками как хотим. С ХП это было бы невозможно (точнее возможно, но потраченного времени и багов было бы на порядок+ больше). Правда стоит отметить, что у нас поверх модели данных есть еще объектная модель (более приближенная к бизнесу), и бизнес-логика работает в основном с этой объектной моделью. Это позволяет инкапсулировать изменения. Т.е. при рефакторинге БД мы чиним внутренности объектной модели (иногда это простейшее обновление маппинга), а остальной код, который работает с этой объектной моделью не меняется.

Ну то есть у вас подход "вначале поломаем, потом будем смотреть, что поломалось и затем уже чинить" вместо того чтобы вначале подумать, что делаете?

Здравствуйте, Олег К., Вы писали:

ОК>Но того, что там есть фундаментальная проблема не отнять.

Фундаментальная это точно. Только не проблема, а глупость.

Здравствуйте, Олег К., Вы писали:

S>>Для HelloWord или вычисления корней квадратного уравнения ты же станешь приватные методы писать правда (я утрирую конечно)?
ОК>Не стану.
Т.е. ты согласен с тем, что инструмент надо применять там, где его применение дает профит? А там, где не дает, там его применять не надо?

S>>А вот от отказа от DAL Игорь, очевидно, профит получает.
ОК>При чем тут ДАЛ? Ты вообще понял о чем речь? База открыта, а ты мне тут про ДАЛ.
DAL — это инструмент преобразования нетипизированных объектов в типизированные и обратно (это просто пример того инструмента, от которого IT отказался и говорит об этом прямо).
Аналогично, слой представлений (View) и хранимых процедур — это инструмент обеспечения некоторой абстракции от структуры таблиц.
Насколько я тебя понял, ты хочешь скрыть от кода, написанного на C# (или C++, или Java, или др.аналогичном языке) структуру БД.
Вопрос в том, нельзя ли от второго инструмента отказаться так же как от первого?

Ты хочешь (поправь, если я ошибаюсь) сделать так, чтобы:
1. БД сама "отвечала" за целостность хранящихся в ней данных и клиентский (по отношению СУБД) код не мог нарушить целостность данных
2. Клиентский (по отношению к СУБД) код взаимодействовал с более высоким уровнем абстракции бизнес-сущностей (например JOIN нескольких таблиц, не заботясь о том, как эта бизнес-сущность "размазана" по таблицам внутри БД).
Применение хранимых процедур и представлений (View) все это может обеспечить. Причем не только теоретически, но и практически.

А зачем надо абстрагироваться от структуры таблиц? Что нам даст слой хранимок, разделяющий слои таблиц БД и клиентский (с точки зрения СУБД) код? Возможность внести изменения в структуру таблиц так, что клиентский код этого не заметит, достаточно будет только слой хранимых процедур поправить? С этим я согласен. В теории.
Но во-первых, часто ли изменение структуры БД выполняется независимо от бизнес-логики (которая на C# написана)? Мне обычно после изменения структуры БД приходится изменения пробрасывать до диалогов, которые видит пользователь, т.е. через все слои до самого верха. И чем больше таких слоев, тем больше изменений.
А во-вторых, даже если абстракция нужна, почему этот слой абстракции должен быть выполнен именно в хранимых процедурах SQL? Почему он не может быть реализован на C#/Java/C++ ? При изменении структуры таблицы (добавление, удаление, переименование, смена типа столбца) где будет проще поправить код работы с таблицей: в нескольких хранимых процедурах (надо вспомнить в каких из нескольких тысяч) или в коде на C# ? При этом надо иметь в виду, что проверифицировать модель данных в C# (чтобы она соответствовала структуре таблиц в БД) можно автоматизированно, и затем при компиляции программы компилятор сам проверит имена столбцов и соответствие типов. А вот соответствие кода хранимых процедур структуре таблицы для процедур, сохраненных до изменения структуры, проверить получится только при обращении к этим хранимкам (в тестах?)
ИМХО на C# проблем огребается меньше... Кроме того, C#/Java/C++ позволяют писать более компактный (и при этом не в ущерб читаемости) код, чем тот же T-SQL (особенности синтаксиса).

Где я не прав?

ОК>Ну и коли ты решил выступить его адвокатом, тогда объясни почему он выборочно так поступает? Дальше, объясни почему он впадает в истерику на справедливое, в принципе, замечание?
Я ничьим адвокатом не выступаю. Просто я довольно давно слежу за "творчеством" IT на этом сайте. И не могу не признать, что он действительно говорит (и, кстати, делает) правильные вещи (хотя мои шаблоны он иногда рвет, да). Я понимаю что говорит тебе Игорь. (или думаю, что понимаю)
Твою основную мысль не очень понимаю.
Твой с IT диалог превратился в холивар. В диалог слепого с глухим. Такое читать весело, но бесполезно.

IT в нескольких постах повторяет одно и то же: практическая целесообразность и эффективность важнее теории.
До сих пор твои возражения звучали как: "неправда, теория важнее". Извини, если что, но со стороны это звучит именно так.

Как понимать этот твой ответ:
S>>Твой же пуристический подход предполагает следование догмам независимо от того нужны ли они и продуктивны ли.
ОК>Это не так. Даже на сиквеле можно писать понятный и поддерживаемый код. Другое дело, что большинство не умеет. Соответственно у большинства будет код на Си шарпе не лучше кода на сиквеле.
?
Ты уверен, что на сегодняшнем уровне развития средств разработки создание и поддержка слоя хранимых процедур, обеспечивающего полную абстракцию от таблиц БД, может быть не менее эффективна, чем применение Linq на "голых" таблицах?
Или же ты допускаешь, что слой абстракции из хранимых процедур более проблематичен, но он должен быть потому что так говорит теория?

Здравствуйте, sushko, Вы писали:

S>Вопрос: а какой сейчас есть мейнстримовый путь работы с базами данных? Ну, например, из MSVisualC или из любого другого средства разработки "общего характера"?

Почему "или"?

Когда можно и из того и и из другого и из третьего. Причем одновременно

Здравствуйте, Олег К., Вы писали:

ОК> linq2db нарушает инкапсуляцию базы,... но лично мне, как purist-у, не просто такое (ORM фреймворки) принять.

Послушайте, ваши сообщения — прямо-таки живая иллюстрация к известной лекции академика Павлова "О русском уме". Вы доктринер, но это плохое качество для инженера.

Можно немного оффтопика?

Linq2DB умеет с работать с SQL Server filestream?

Здравствуйте, Somescout, Вы писали:

S>Linq2DB умеет с работать с SQL Server filestream?

Если маппинг прописать, то можно работать с чем угодно.

Если это оно, то тут есть один маленький ньюанс. Здесь используется using для SqlFileStream объекта. Если нужна такая же функциональность, то нужно подумать в каком виде это лучше организовать. По идее работы на час, главное придумать в каком виде это должно быть.

Здравствуйте, MasterZiv, Вы писали:

MZ>Ты наверное не поверишь -- СНОВА ODBC!

А что ADO уже не? А почему?

Здравствуйте, TrimS, Вы писали:

MZ>>Ты наверное не поверишь -- СНОВА ODBC!

TS>А что ADO уже не? А почему?

А это -- не ко мне вопрос, а к тем, кто придумал это ADO.

Здравствуйте, Olaf, Вы писали:

MC>>Переименование

O>Все объекты БД можно переименовать Refactor -> Rename (F2), причем переименовывается не только сам объект, но и все ссылки на него в связанных объектах и скриптах.

И даже в отрыжке вида

declare @whereClause nvarchar(200)

if @foo = 1
  set @whereClause = @whereClause + ' and Foo = 1'
else
  set @whereClause = @whereClause + ' and Bar = 1'

?

Здравствуйте, Нахлобуч, Вы писали:

O>>Все объекты БД можно переименовать Refactor -> Rename (F2), причем переименовывается не только сам объект, но и все ссылки на него в связанных объектах и скриптах.

Н>И даже в отрыжке вида
Н>...
Н>?

Переименовать можно только объекты БД (Таблицы, колонки, представления, ХП, функции и прочее). Поддержку работы с переменными обещали сделать в следующих версиях SSDT.