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

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

I>>Наверное им сказали "надо сделать шоп без диаграм". Ну и они сделали, как поняли.
I>>А вообще за рантайм генерацию БД по дефалту надо кастрировать прилюдно.
Кгм, это чревато потерей данных, о чем я уже писал выше. Понятное дело что, тут необходимы кривые руки разработчиков, но фреймворк должен иметь защиту от дурака, а тут прям таки провоцируют такое поведение. За шо и надо стрелять.

C>А тех кто пихает в БД логику — расстреливать прилюдно.
Тех кто пихает в БД логику без веских на то оснований надо расстреливать. Поддерживаю.

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

I>Кгм, это чревато потерей данных, о чем я уже писал выше. Понятное дело что, тут необходимы кривые руки разработчиков, но фреймворк должен иметь защиту от дурака, а тут прям таки провоцируют такое поведение. За шо и надо стрелять.
Это понятно, что ты хочешь от инструмента то, что он по умолачанию делает другое.
1) Вместо воцклицаний стоило бы отдать должное, что всё это настраивается, и ты об этом осведомлён. Кого парят умолчания? Они никогда не используются то и так.
2) Я всю жизнь желаю, что бы string.Format работал в инвариантной культуре, т.к. для МОИХ задач важно, что бы как раз она не учитиывалась, а если где-то учитывалась — то явно. Но так вот, не нужно всех равнять на себя. Хватит уже. Ну сделали и сделали. Настраивается — настраивается. Можно было бы лучше? Можно было бы! Стоит ли вообще EF юзать — не стоит, забейте на него болт и забудьте, чего столько криков. Щас БД не так создаётся, потом "энтити" (хотя откруда там взяться энтити если там не энтити), потом не понравится ещё что-нибудь.... когда видимо дело дойдёт. Я опять же — не хочу принижать никого, но в моей практике EF показал себя наихудшим образом, — крутых няшек и фяшек вокруг него есть много и в том числе интересных, но выхлоп — ужасен от всего этого. Инструмент достойный, но общественная истерия по UoW и прочему — и т.п. — просто сводит это всё на нет. А с ноля — я бы юзал BLToolkit — это было бы и проще и намного эффективнее, при чём в обоих смыслах эффективности.
Ну за сим я закончил разговор на эту тему.

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

I>>>А вообще за рантайм генерацию БД по дефалту надо кастрировать прилюдно.
I>Кгм, это чревато потерей данных, о чем я уже писал выше. Понятное дело что, тут необходимы кривые руки разработчиков, но фреймворк должен иметь защиту от дурака, а тут прям таки провоцируют такое поведение. За шо и надо стрелять.
Потеря данных решается административными мерами по ограничению доступа к БД и разделению production/development. Иначе случайно набрать "drop table" можно и так.

Я вообще не понимаю в чём проблема. У себя я генерирую дельта-скрипты для апдейта базы из модели в коде, к примеру.

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

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

I>>>>А вообще за рантайм генерацию БД по дефалту надо кастрировать прилюдно.
I>>Кгм, это чревато потерей данных, о чем я уже писал выше. Понятное дело что, тут необходимы кривые руки разработчиков, но фреймворк должен иметь защиту от дурака, а тут прям таки провоцируют такое поведение. За шо и надо стрелять.
C>Потеря данных решается административными мерами по ограничению доступа к БД и разделению production/development. Иначе случайно набрать "drop table" можно и так.

drop можно запретить, но вот insert или update в таблицах которые хранят данные не запретишь, всегда будет логин/пароль под которым изменение возможно , иначе тот же сервер приложений не сможет ничего добавить или изменить.
а изменением этих данных и нужно следить, обычно с помощью триггеров.
Либо за целостностью, когда логика отлична от null/не null. Например в поле "Описание" не должно быть не русских символов.Или дата не может быть меньше текущей.
Это свойство хранилища и должно быть ограничено на уровне хранилища, иначе какой-нибудь вася пупкин под логином аппсервера изменит поле неверным образом или создаст платеж с прошлой датой.


вообще не понимаю в чём проблема. У себя я генерирую дельта-скрипты для апдейта базы из модели в коде, к примеру.

Не все можно проапдейтить таким образом. Иногда требуется сделать хитрый update, например конвертнуть из строки в несколько новых полей.
В любом случае приходится без аппсервера работать с базой, все механизмы по защите целостности и корректности данных должны быть на уровне БД, чтобы нельзя было в обход аппсервера что-то сломать.

Здравствуйте, Аноним, Вы писали:

А>Либо за целостностью, когда логика отлична от null/не null. Например в поле "Описание" не должно быть не русских символов.Или дата не может быть меньше текущей.
А>Это свойство хранилища и должно быть ограничено на уровне хранилища, иначе какой-нибудь вася пупкин под логином аппсервера изменит поле неверным образом или создаст платеж с прошлой датой.
Ну и делать это средствами валидации на уровне модели. В .NET/Java они есть.

Иначе на банальнейших вещах будут проблемы — типа подсветки ошибок на веб-формах "на лету".

C>>вообще не понимаю в чём проблема. У себя я генерирую дельта-скрипты для апдейта базы из модели в коде, к примеру.
А>Не все можно проапдейтить таким образом. Иногда требуется сделать хитрый update, например конвертнуть из строки в несколько новых полей.
В таких случаях дописываю нужные вещи руками.

А>В любом случае приходится без аппсервера работать с базой, все механизмы по защите целостности и корректности данных должны быть на уровне БД, чтобы нельзя было в обход аппсервера что-то сломать.
Ну так не нужно работать с БД в обход аппсервера.

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

C>Здравствуйте, Аноним, Вы писали:

А>>Либо за целостностью, когда логика отлична от null/не null. Например в поле "Описание" не должно быть не русских символов.Или дата не может быть меньше текущей.
А>>Это свойство хранилища и должно быть ограничено на уровне хранилища, иначе какой-нибудь вася пупкин под логином аппсервера изменит поле неверным образом или создаст платеж с прошлой датой.
C>Ну и делать это средствами валидации на уровне модели. В .NET/Java они есть.

Средства валидации на уровне constrains таблицы не всегда могут реализовать нужную логику.
Либо ее нужно описать опять же в хранимке.


C>Иначе на банальнейших вещах будут проблемы — типа подсветки ошибок на веб-формах "на лету".
Это о чем , не совсем понятна проблема...

C>>>вообще не понимаю в чём проблема. У себя я генерирую дельта-скрипты для апдейта базы из модели в коде, к примеру.
А>>Не все можно проапдейтить таким образом. Иногда требуется сделать хитрый update, например конвертнуть из строки в несколько новых полей.
C>В таких случаях дописываю нужные вещи руками.
В обход же аппсервера ?

А>>В любом случае приходится без аппсервера работать с базой, все механизмы по защите целостности и корректности данных должны быть на уровне БД, чтобы нельзя было в обход аппсервера что-то сломать.
C>Ну так не нужно работать с БД в обход аппсервера.
А как дописываете нужные вещи руками ?

Здравствуйте, Аноним, Вы писали:

C>>Ну и делать это средствами валидации на уровне модели. В .NET/Java они есть.
А>Средства валидации на уровне constrains таблицы не всегда могут реализовать нужную логику.
И что?

А>Либо ее нужно описать опять же в хранимке.
Не нужно. Есть средства валидации, работающие на уровне модели.

C>>Иначе на банальнейших вещах будут проблемы — типа подсветки ошибок на веб-формах "на лету".
А>Это о чем , не совсем понятна проблема...
Вот я ввожу данные на форму. Хочется валидировать их прямо в браузере JavaScript'ом. В крайнем случае, на сервере с помощью AJAX-запросов.

Каким образом я это могу сделать с использованием хранимок? С валидацией на уровне модели всё просто.

C>>В таких случаях дописываю нужные вещи руками.
А>В обход же аппсервера ?
Да, для миграций схемы БД, которые требуют особых действий.

А>>>В любом случае приходится без аппсервера работать с базой, все механизмы по защите целостности и корректности данных должны быть на уровне БД, чтобы нельзя было в обход аппсервера что-то сломать.
C>>Ну так не нужно работать с БД в обход аппсервера.
А>А как дописываете нужные вещи руками ?
Я не дописываю "нужные вещи" руками.

Здравствуйте, Аноним, Вы писали:

K>>Кто сказал, что медленно? Результаты бенчмарков в студию. И не забываем про batch queries. Плюс непонятно, почему для вставки дочерних сущностей делается insert ... select? Сразу нельзя ими обойтись?

А>Можно если они в одном списке, а если это структура из двух списков Parent-Child то не получится.

Опять я не понимаю, о чём идёт речь. Какая структура, какие списки?

А>А это с чего такой вывод ? Oracle хранилище и ХП и триггера обеспечивают именно функцию хранилища.
А>А бизнес-логику пиши на чем угодно. Нет смысла хранилище над хранилищем надстраивать.

А зачем хранилищу триггеры? Почему стандартных insert/update/delete не хватает? Ну вот то же протоколирование, или security. Но тогда вопрос: а "ведение протокола изменения такой-то сущности" — это что, функции хранилища, или часть бизнес-логики? Или тот же security. Скажем, такое правило "редактировать данный документ может сотрудник, создавший его, или любой другой сотрудник из одного с ним отдела" — это функции хранилища или бизнес-логики? Даже такая элементарная вещь "поле "дата" должно быть заполнено" — вполне себе требование бизнес-логики, которое выражается в терминах SQL-базы. Вот тогда вопрос: зачем часть логики выносить в БД, а часть — реализовывать снаружи?

K>>Ну наверное, если работаем с EF, надо думать в терминах объектов, а не в терминах вставки строчек в таблички?
А>Ну думай в терминах объектов кто же мешает, объясни только как ты запротоколируешь что изменилась строка в таблице хранилища и кто ее изменил из какого клиента, с какой машини сети ? В триггере это пишется легко, давай через твой любимый внешний сервис в EF как ты грозился это решить ? Еще учитывая что сервер БД может работать, а твой сервис по какой-то причине лежать, то изменения в БД могут произойти а протоколировать некому.

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

Как через EF решить не знаю, через Hibernate решается написанием interceptor'а, который срабатывает при записи в БД изменений в определённой сущности и собственно осуществляет протоколирование.

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

C>Нормально всё сделали.
Нормального там вообще ничего нет, криво все и через жопу. Попытались скрестить ужа с кактусом и в итоге встали в раскоряку — и лишнее толком не выпилили и новое прикрутить нормально не смогли.
Уродец, короче, как был им, так и остался.

C> А тех кто пихает в БД логику — расстреливать прилюдно.
Ну это уже твоя личная боль, к данному вопросу это отношения не имеет )