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

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

А можно аргументировано? Что конкретно является злом? ИМХО, как раз руки надо отрывать за генерацию страшных исходников на основе непонятного XML, который редактировать нужно через редактор диаграмм.

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

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

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

Наверное им сказали "надо сделать шоп без диаграм". Ну и они сделали, как поняли.
А вообще за рантайм генерацию БД по дефалту надо кастрировать прилюдно.

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

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

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

Почему они до сих пор на свободе, не найдены и не переданы суду ?

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

I>К "EF with POCO" вопросов много, но ет шаг в правильном направлении.
I>Но главная проблема в названии "code first" и соответственно к попыткам сгенерить базу на основе модели неявно в рантайме при каждом запуске. А если же база уже существыует и слегка не соответствует модели, то вечер перестает быть томным.
Это просто инструмент, который может быть полезен на раннем этапе разработки, кстати они его и рекомендуют использовать только пока ты работаешь один и вносишь много правок в модель. Затем эта автогенерация в любом случае отключается, и заменяется либо миграциями (хоть EF, хоть альтернативными) — или же вообще БД начинает жить отдельно, а изменения в модель вносятся в ручную / генерируется по БД (хотя тут уже средств EF маловато, BLT-шный генератор получается гораздо вкуснее).

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

Это была ирония, на тему когда к БД подключается неизвестно кто и что-то в ней меняет, в обход сервера приложений.
Такое конечно же может быть — но, это ровно два случая:
1) космос
2) это так и задумывалось
Поэтому о чём был плач — остался неясен.

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

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

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

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

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

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

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

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

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

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

K>А можно аргументировано? Что конкретно является злом? ИМХО, как раз руки надо отрывать за генерацию страшных исходников на основе непонятного XML, который редактировать нужно через редактор диаграмм.
К "EF with POCO" вопросов много, но ет шаг в правильном направлении.
Но главная проблема в названии "code first" и соответственно к попыткам сгенерить базу на основе модели неявно в рантайме при каждом запуске. А если же база уже существыует и слегка не соответствует модели, то вечер перестает быть томным.

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

K>А можно аргументировано? Что конкретно является злом? ИМХО, как раз руки надо отрывать за генерацию страшных исходников на основе непонятного XML, который редактировать нужно через редактор диаграмм.

А что за страшные исходники на основе непонятного XML ? Никогда не пользовался и вам не советую этот кошмар.
Сгенерите мне по CodeFirst Oracle-Type

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

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

F> Это просто инструмент, который может быть полезен на раннем этапе разработки, кстати они его и рекомендуют использовать только пока ты работаешь один и вносишь много правок в модель. Затем эта автогенерация в любом случае отключается, и заменяется либо миграциями (хоть EF, хоть альтернативными) — или же вообще БД начинает жить отдельно, а изменения в модель вносятся в ручную / генерируется по БД (хотя тут уже средств EF маловато, BLT-шный генератор получается гораздо вкуснее).
Спасибо кэп
Можно конечно дискутировать о полезности этой фичи даже на ранних этапах разработки(я считаю абсолютно бессмысленная и бесполезная), однако она включена по умолчанию. И за это надо сильно бить ногами.

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

А>А что за страшные исходники на основе непонятного XML ? Никогда не пользовался и вам не советую этот кошмар.
А>Сгенерите мне по CodeFirst Oracle-Type

Что такое Oracle-Type?

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

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

А>>А что за страшные исходники на основе непонятного XML ? Никогда не пользовался и вам не советую этот кошмар.
А>>Сгенерите мне по CodeFirst Oracle-Type

K>Что такое Oracle-Type?

http://www.oracle-base.com/articles/8i/object-types.php

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

А>>>А что за страшные исходники на основе непонятного XML ? Никогда не пользовался и вам не советую этот кошмар.
А>>>Сгенерите мне по CodeFirst Oracle-Type

K>>Что такое Oracle-Type?

А>http://www.oracle-base.com/articles/8i/object-types.php

Не припомню, чтобы что-то подобное мне когда-либо приходилось использовать А так, в чём проблема? Выполнить произвольный SQL никто не мешает. Зачем DDL генерить с помощью EF? Я пишу на Java, там Hibernate вместо EF и есть hbm2ddl, которым я не пользуюсь. А пользуюсь я Liquibase, для которого в .NET должны быть аналоги.

А вообще, если есть Oracle с его наворотами, то зачем вообще плодить сверху какие-то EF? Я всегда думал, что есть два лагеря. Один — это ораклисты, когда всё-всё-всё делают с помощью Oracle (там поистине потрясающие возможности, так что ЯП общего назначения сверху даже не нужны), другой — это когда берут тот самый ЯП общего назначения и реализуют на нём всю бизнес-логику. Вот никогда не понимал людей, которые одну часть бизнес-логики засовывают в триггеры и хранимки, а другую прикручивают сверху. Это непоследовательно, и запутывает программу.

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

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

А>>>>А что за страшные исходники на основе непонятного XML ? Никогда не пользовался и вам не советую этот кошмар.
А>>>>Сгенерите мне по CodeFirst Oracle-Type

K>>>Что такое Oracle-Type?

А>>http://www.oracle-base.com/articles/8i/object-types.php

K>Не припомню, чтобы что-то подобное мне когда-либо приходилось использовать
Придется еще, когда нужно будет

1) передавать и сохранять в базу иерархию объектов, вместо того чтобы сначала Child создавать в базе, потом получать их ID и привязывать к Parent, объектами это делается красиво.

2) передавать большое количество параметров.

Это на уровне чисто использования как сложной структуры и меппинга с программой ( без ООП , т.е. описания методов этого типа и т.д. ).


Хранимки триггеры и БЛ на уровне приложения никак не исключают друг друга.
Хранимка это не обязательно БЛ , это метод для сохранения или получения данных.
Логика сохранения или получения данных не всегда ограничивается одним запросом.
Реализовывать логику каждый раз в разных программных модулях которые будут работать с хранилищем — дублирование кода и ответственности.

Триггеры это еще меньше привязано к БЛ, это может быть сохранение истории таблицы, исходные данные, кто менял и т.д.
Т.е. отвественность хранилища, т.к. поменять данные в таблице могут как из программы так и из visual studio, триггеры гарантируют сохранение истории по таблице и не только, это никак не связано с БЛ.

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

А>1) передавать и сохранять в базу иерархию объектов, вместо того чтобы сначала Child создавать в базе, потом получать их ID и привязывать к Parent, объектами это делается красиво.

Во-первых, зачем создавать, чтобы получить ID, когда можно использовать sequences? Во-вторых, если используется ORM, то зачем вообще думать о подобных вещах?

А>Хранимки триггеры и БЛ на уровне приложения никак не исключают друг друга.
А>Хранимка это не обязательно БЛ , это метод для сохранения или получения данных.
А>Логика сохранения или получения данных не всегда ограничивается одним запросом.
А>Реализовывать логику каждый раз в разных программных модулях которые будут работать с хранилищем — дублирование кода и ответственности.

Не выставлять наружу БД. Выставлять сервер приложений Не считая, конечно, всякой аналитики и OLAP, но там вряд ли понадобятся какие-либо имеющиеся хранимки или EF. Ну или если хочется идти оракловским путём — то зачем тогда вообще ORM?

А>Триггеры это еще меньше привязано к БЛ, это может быть сохранение истории таблицы, исходные данные, кто менял и т.д.

ORM поддерживают всяческие перехватчики и хуки. Да и опять же, всё это на уровне сервера приложений можно реализовать.

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

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

А>>1) передавать и сохранять в базу иерархию объектов, вместо того чтобы сначала Child создавать в базе, потом получать их ID и привязывать к Parent, объектами это делается красиво.

K>Во-первых, зачем создавать, чтобы получить ID, когда можно использовать sequences? Во-вторых, если используется ORM, то зачем вообще думать о подобных вещах?

Потому что в ORM это будет медленно работать
вместо

insert into t1
select parent_id, tsrc.a, tsrc.b from table( my_object_collection ) tsrc;

нужно будет вызывать insert для каждого дочернего элемента.

А>>Хранимки триггеры и БЛ на уровне приложения никак не исключают друг друга.
А>>Хранимка это не обязательно БЛ , это метод для сохранения или получения данных.
А>>Логика сохранения или получения данных не всегда ограничивается одним запросом.
А>>Реализовывать логику каждый раз в разных программных модулях которые будут работать с хранилищем — дублирование кода и ответственности.

K>Не выставлять наружу БД. Выставлять сервер приложений Не считая, конечно, всякой аналитики и OLAP, но там вряд ли понадобятся какие-либо имеющиеся хранимки или EF. Ну или если хочется идти оракловским путём — то зачем тогда вообще ORM?

Сервер приложений , зачем ? А если нужно использовать Load/Save в каком-нибудь Job, писать код который будет вызывать методы сервера приложений? Это только снизит надежность.
По сути Oracle это и есть сервер хранилище и если даже городить еще одну прослойку для доступа к хранилищу, то базовые вещи как сохранение какой-то сущности или ее загрузка должны быть на уровне хранилища, а в прослойке можно вывести нужные сущности или как-то адаптировать интерфейс под конкретную задачу.


А>>Триггеры это еще меньше привязано к БЛ, это может быть сохранение истории таблицы, исходные данные, кто менял и т.д.

K>ORM поддерживают всяческие перехватчики и хуки. Да и опять же, всё это на уровне сервера приложений можно реализовать.
как на EF создашь перехватчик, чтобы когда я подключившись sql plus вставив в таблицу запись это запротоколировалось.

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

K>>Во-первых, зачем создавать, чтобы получить ID, когда можно использовать sequences? Во-вторых, если используется ORM, то зачем вообще думать о подобных вещах?

А>Потому что в ORM это будет медленно работать
А>вместо

А>insert into t1
А> select parent_id, tsrc.a, tsrc.b from table( my_object_collection ) tsrc;

А>нужно будет вызывать insert для каждого дочернего элемента.

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

А>Сервер приложений , зачем ? А если нужно использовать Load/Save в каком-нибудь Job, писать код который будет вызывать методы сервера приложений? Это только снизит надежность.

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

С таким подходом зачем вообще EF и .NET? Всё на Oracle

А>>>Триггеры это еще меньше привязано к БЛ, это может быть сохранение истории таблицы, исходные данные, кто менял и т.д.

K>>ORM поддерживают всяческие перехватчики и хуки. Да и опять же, всё это на уровне сервера приложений можно реализовать.
А>как на EF создашь перехватчик, чтобы когда я подключившись sql plus вставив в таблицу запись это запротоколировалось.

Ну наверное, если работаем с EF, надо думать в терминах объектов, а не в терминах вставки строчек в таблички?

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

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

K>>>Во-первых, зачем создавать, чтобы получить ID, когда можно использовать sequences? Во-вторых, если используется ORM, то зачем вообще думать о подобных вещах?

А>>Потому что в ORM это будет медленно работать
А>>вместо

А>>insert into t1
А>> select parent_id, tsrc.a, tsrc.b from table( my_object_collection ) tsrc;

А>>нужно будет вызывать insert для каждого дочернего элемента.

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

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

А>>Сервер приложений , зачем ? А если нужно использовать Load/Save в каком-нибудь Job, писать код который будет вызывать методы сервера приложений? Это только снизит надежность.

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

K>С таким подходом зачем вообще EF и .NET? Всё на Oracle

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


А>>>>Триггеры это еще меньше привязано к БЛ, это может быть сохранение истории таблицы, исходные данные, кто менял и т.д.

K>>>ORM поддерживают всяческие перехватчики и хуки. Да и опять же, всё это на уровне сервера приложений можно реализовать.
А>>как на EF создашь перехватчик, чтобы когда я подключившись sql plus вставив в таблицу запись это запротоколировалось.

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

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

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

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

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

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

Ну а сервер приложений как от такого защитит ? Также зайдут и дропнут. Для защиты от таких действий настраиваются политики безопасности опять же БД, а не пишется отдельно стоящий сервис который будет разрешать или запрещать.

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

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

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

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

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

Здравствуйте, 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>>Ну так не нужно работать с БД в обход аппсервера.
А>А как дописываете нужные вещи руками ?
Я не дописываю "нужные вещи" руками.

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

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

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