Я считаю так.
Если система целиком в пределах ваших, вашей конторы или ещё как-то контролируется, либо есть архитектурная группа, которая контролирует разработку через множество подрядчиков прямым демократическим образом, вы выработаете архитектуру и ФОРМАЛЬНЫЕ правила для моделирования и преобразования в код и в базу. И даже можете это автоматизировать. Народ пишет свои фреймворки, свои слои для доступа к данным, чтобы СЕБЕ обеспечить слабосвязанность на будущие изменения. Кто-то даже при этом генераторы кода пишет для повышения производительности, суть, на чём, не важна, T4 там или ещё что.
Системы, в которых этому не следуют, суть — не имеют архитектуры, а по-русски безобразны. Примеров этому — много, противоположных, — мало.
Если нужна интеграция с чужой системой именно на уровне СУБД, тут начинаются варианты. Однако, неплохо иметь ORM, который позволяет настроиться на чужую базу тем или иным образом.
Диаграмма помогает как минимум сразу оценить систему и проще понимать структуру базы. Причем, диаграмма рисованная человеком. Хоть понятно, о чем люди думали, когда проектировали.
Я уже соглашаюсь в очередной раз, что инструменты надо знать лучше, предела совершенству нет. Меня просто удивило, что народ решает проблемы, которые и решать-то вроде не надо (я просто не сталкивался).
Я расскажу, потерпите.
Вещь очень хорошая, как и всё, тоже не лишенная недостатков и разных приколов, которые объясняются как спецификой восприятия реальности создателями, так и разными историческими причинами (очень много прикладного кода). Потерпите, пожалуйста, немного.
… а потом однажды он чуть-чуть ошибется в том, какое значение когда было прочитано, и все, прощайте деньги у кого-то на счету.
Если значение всегда меняется на относительную величину, должна ошибиться СУБД.
Я такого чуда нигде никогда не видел, сколько живу (разве что в древних-древних версиях MySQL).
Ясно. Удачи.
Особенно, когда вам придётся масштабировать сервер приложений на несколько физических машин. Причём убавлять-добавлять при необходимости.
А я попользуюсь более простым средством: ORM просто вычтет или прибавит, если я скажу, что это значение надо учитывать как относительное.
У меня не возникнет проблем ни с изучением, настройкой и т.п. реактивных фреймворков. Также, у меня не возникает привязки к СУБД (ANSI-стандарт) и, если что, я перееду на другую, не изменяя прикладного кода.
И потом, настройку реактивных фреймворков никак не сочтёшь тонкой настройкой codefirst, уж как ни крути.
Пример:
Идут платежи 300 шт. в секунду.
На каждый в БД создаётся запись о «транзакции», т.е. изменение суммы.
Текущее состояние счёта как станете пересчитывать, чтобы показать пользователю?
Говорить: ай, concurrency conflict?
Но ведь вы согласитесь со мной, что такой способ создаёт бОльшую нагрузку на СУБД, нежели просто использовать относительные значения?
И потом, мне ошибка контроля конкуренции не нужна. Мне молча нужно получить 300 в этом поле этой записи в БД и всё.
Я запрос не придумывал, я просто иллюстрирую проблему concurrency, которая, при нагруженных системах с множеством транзакций не решается толком никак по-другому, ибо управление конкуренцией на уровней приложения сильно ограничивает архитектуру и возможности масштабирования, соответственно усложняет логику (это всё чревато глюками).
Меня упрекнули в том, что всё можно настроить. Я попросил пример, когда нужно вычислительную логику передвинуть на уровень СУБД, если это необходимо. Ну и вообще что угодно вытворить, если очень приспичит.
Иногда думать как БД — приходится. Её же никуда не денешь.
Другое дело, что прикладной код нужно стараться максимально изолировать от этой специфики.
Я к тому, что не хочу разбираться на уровне приложения с конкуренцией. С т.з. повышения конкуренции, лучше вообще отдать этот вопрос СУБД, о чём я и толкую.
Что угодно считать. Например, деньги.
Как решать следующую задачу:
Есть сущность Счет.
Есть объект в базе, у которого Счет.Сумма=100.
1. Два процесса подняли этот объект одновременно (ну, почти одновременно).
2. Затем первый сказал что Счет.Сумма нужно увеличить на 100.
3. Второй сказал что Счет.Сумма нужно увеличить ещё 100.
4. В базе Счет.Сумма = 300 (должно быть).
Как вы бы решали эту задачу?
Если пишутся константные значения, то будет бага, ибо запишется 200, т.к. второй перепишет значение первого.
В плане проектирования от модели с диаграммы классов я с вами согласен на 100% всеми конечностями, просто инструмент другой у меня. И в плане донастройки в коде, тоже. Позиция моя в том, что в код лезть надо только за очень тонкими настройками.
К сожалению, назвать инструмент я не могу, я уверен, это сочтут открытой рекламой, что противоречит правилам. Но рассказать про него я обещаю в продолжении. Надеюсь, я смогу его выпустить. Пожалуйста, дождитесь продолжения.
Я ни за тех, ни за других. Когда-то так, когда-то эдак. Бывает много факторов, самых неожиданных. Я вам привёл пример, когда идентификатор сущности надо знать сразу, иначе потом концов не собрать.
CodeFirst позволяет настроить все очень тонко и очень детально. Но Вы в упор отказываетесь это принять. Только в этом Ваша проблема.
Ок. Приведите мне пример, как настроить следующее: вот мне надо, чтобы когда идёт update запрос на обновление числового поля в БД, ORM не просто тупо подставил значение как константу (x = значение), а выражением, как разницу между значением, которое было при зачитывании и при обновлении (как x = x + РазницаСтарогоИНовогоЗначений). Я надеюсь, вы понимаете, зачем такое может быть нужно.
Я считаю так.
Если система целиком в пределах ваших, вашей конторы или ещё как-то контролируется, либо есть архитектурная группа, которая контролирует разработку через множество подрядчиков прямым демократическим образом, вы выработаете архитектуру и ФОРМАЛЬНЫЕ правила для моделирования и преобразования в код и в базу. И даже можете это автоматизировать. Народ пишет свои фреймворки, свои слои для доступа к данным, чтобы СЕБЕ обеспечить слабосвязанность на будущие изменения. Кто-то даже при этом генераторы кода пишет для повышения производительности, суть, на чём, не важна, T4 там или ещё что.
Системы, в которых этому не следуют, суть — не имеют архитектуры, а по-русски безобразны. Примеров этому — много, противоположных, — мало.
Если нужна интеграция с чужой системой именно на уровне СУБД, тут начинаются варианты. Однако, неплохо иметь ORM, который позволяет настроиться на чужую базу тем или иным образом.
Я уже соглашаюсь в очередной раз, что инструменты надо знать лучше, предела совершенству нет. Меня просто удивило, что народ решает проблемы, которые и решать-то вроде не надо (я просто не сталкивался).
Вещь очень хорошая, как и всё, тоже не лишенная недостатков и разных приколов, которые объясняются как спецификой восприятия реальности создателями, так и разными историческими причинами (очень много прикладного кода). Потерпите, пожалуйста, немного.
Если значение всегда меняется на относительную величину, должна ошибиться СУБД.
Я такого чуда нигде никогда не видел, сколько живу (разве что в древних-древних версиях MySQL).
Особенно, когда вам придётся масштабировать сервер приложений на несколько физических машин. Причём убавлять-добавлять при необходимости.
А я попользуюсь более простым средством: ORM просто вычтет или прибавит, если я скажу, что это значение надо учитывать как относительное.
У меня не возникнет проблем ни с изучением, настройкой и т.п. реактивных фреймворков. Также, у меня не возникает привязки к СУБД (ANSI-стандарт) и, если что, я перееду на другую, не изменяя прикладного кода.
И потом, настройку реактивных фреймворков никак не сочтёшь тонкой настройкой codefirst, уж как ни крути.
Идут платежи 300 шт. в секунду.
На каждый в БД создаётся запись о «транзакции», т.е. изменение суммы.
Текущее состояние счёта как станете пересчитывать, чтобы показать пользователю?
Говорить: ай, concurrency conflict?
И потом, мне ошибка контроля конкуренции не нужна. Мне молча нужно получить 300 в этом поле этой записи в БД и всё.
Меня упрекнули в том, что всё можно настроить. Я попросил пример, когда нужно вычислительную логику передвинуть на уровень СУБД, если это необходимо. Ну и вообще что угодно вытворить, если очень приспичит.
Иногда думать как БД — приходится. Её же никуда не денешь.
Другое дело, что прикладной код нужно стараться максимально изолировать от этой специфики.
Процессы исполняются на физически разных машинах.
Как решать следующую задачу:
Есть сущность Счет.
Есть объект в базе, у которого Счет.Сумма=100.
1. Два процесса подняли этот объект одновременно (ну, почти одновременно).
2. Затем первый сказал что Счет.Сумма нужно увеличить на 100.
3. Второй сказал что Счет.Сумма нужно увеличить ещё 100.
4. В базе Счет.Сумма = 300 (должно быть).
Как вы бы решали эту задачу?
Если пишутся константные значения, то будет бага, ибо запишется 200, т.к. второй перепишет значение первого.
К сожалению, назвать инструмент я не могу, я уверен, это сочтут открытой рекламой, что противоречит правилам. Но рассказать про него я обещаю в продолжении. Надеюсь, я смогу его выпустить. Пожалуйста, дождитесь продолжения.
Я ни за тех, ни за других. Когда-то так, когда-то эдак. Бывает много факторов, самых неожиданных. Я вам привёл пример, когда идентификатор сущности надо знать сразу, иначе потом концов не собрать.
Ок. Приведите мне пример, как настроить следующее: вот мне надо, чтобы когда идёт update запрос на обновление числового поля в БД, ORM не просто тупо подставил значение как константу (x = значение), а выражением, как разницу между значением, которое было при зачитывании и при обновлении (как x = x + РазницаСтарогоИНовогоЗначений). Я надеюсь, вы понимаете, зачем такое может быть нужно.