Сообщение Re[28]: А как сейчас модно работать с БД из-под Windows? от 21.09.2015 12:17
Изменено 21.09.2015 12:18 stomsky
Здравствуйте, Олег К., Вы писали:
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 на "голых" таблицах?
Или же ты допускаешь, что слой абстракции из хранимых процедур более проблематичен, но он должен быть потому что так говорит теория?
Кстати, а что плохого в том, что вышележащий слой (бизнес-логика на C#) знает как устроена база данных?
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 на "голых" таблицах?
Или же ты допускаешь, что слой абстракции из хранимых процедур более проблематичен, но он должен быть потому что так говорит теория?
Кстати, а что плохого в том, что вышележащий слой (бизнес-логика на C#) знает как устроена база данных?
Здравствуйте, Олег К., Вы писали:
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 на "голых" таблицах?
Или же ты допускаешь, что слой абстракции из хранимых процедур более проблематичен, но он должен быть потому что так говорит теория?
Кстати, а что плохого в том, что вышележащий слой (бизнес-логика на C#) знает как устроена база данных?
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 на "голых" таблицах?
Или же ты допускаешь, что слой абстракции из хранимых процедур более проблематичен, но он должен быть потому что так говорит теория?
Кстати, а что плохого в том, что вышележащий слой (бизнес-логика на C#) знает как устроена база данных?