Опять ДБ трабл.

[jes]

Жень, ты путаешь консистентность ДБ и валидность дат туда пихаемых. Кострейнтами не все решишь, особенно строго форматированный текст для внешней системы ( а таких мест много, специфика ) или формат записи... хм хм... например ИБАН число что оно записано правильно ты сможешь это проверить на уровне ДБ?

[alp]

Что-то мне не встречались вещи, которые нельзя проверить на уровне БД

Еще вариант не нагружать логикой ограничений и триггеров БД, но ограничить доступ к данным из других приложений.

[AgentXXX]

Женя, проверки в базе - это нечто одно.В программе - это что-то другое.

ИМХО.Активное использование триггеров возможно при наличии человека необременённого на 800% текучкой, а имеющем время всё сделать не быстро и комсомольскими темпами без единой доки(попутно поддерживая существующие и растущие с геометрической прогрессией запросы от бизнеса), а с толком-чувством-расстановкой.Иначе будет хаос с полными непонятками от забытых триггеров.

Триггеры - они такие, о них принято забывать.

Да и ДБА нужен толковый.

Короче, придумали хороший проект.Но реализовать его нужно было больше времени и людей раза в 3 больше.

А теперь - имеем что имеем.

 

Что-то мне не встречались вещи, которые нельзя проверить на уровне БД

Приведен пример - IBAN.

Юзверь его записывает и сразу должен знать, что заполнил правильно.А правил на его заполнение немало.

На уровне ЮИ решается достаточно просто.

Не будешь же ИБАНы для всег стран триггерами проверять после укладывания в дб и возвращать назад в аппликашку.

[Yevgen35]

Не будешь же ИБАНы для всег стран триггерами проверять после укладывания в дб и возвращать назад в аппликашку.

А какие собственно проблемы?

Вообще-то триггер(Before-Insert) в Oracle срабатывает в момент вставки данных в БД и в случае ошибки генерит сообщение об ошибке которое не сложно поймать клиентским приложением.

Это и есть твой валидатор.

Тут у меня вдуг всплыло в памяти, что каких-то видов триггеров в MSSQL просто нет только не помню каких точно, кажется это триггеры Before-Insert, Before-Update и Before-Delete.

Тогда понятны ваши трудности.

 

Ты безусловно можешь делать проверки в ЮИ как тебе хочется,

но в таблицу не должны попадать левые данные.

Полюбому. Чистота данных превыше всего.

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

Докажи, мне что эти данные не были вставленны через ЮИ?

Никак не докажешь, и логгирование тоже никак не сделаешь, потому как делать его надо на уровне БД.

[jes]

Типа извечный спор, где логику держать, на уровне ДБ или на уровне аппликации...

Безсмысленно

[alp]

Вот как раз и нужно проверять в базе. Чтобы потом не поиметь "бардак на зоне". Интерфейс - это из другой оперы. Пускай и там проверяется, если нужно. Чтобы код не плодить, можно просто оформить в виде функции в базе, и вызывать её когда нужно. Я так понимаю производительность при проверке IBAN не замеряется на доли секунды? Не такая частая операция по идее..

 

Я понимаю, что идеала не бывает Сам вижу постоянно кривые базы..

Имхо данные, в конечном итоге, для того самого бизнеса важнее, чем сам код. Тем более если этот код не обеспечивает качество этих самых данных.

 

 

Типа извечный спор, где логику держать, на уровне ДБ или на уровне аппликации...

Безсмысленно

 

Ясен пень Че тут спорить - в базе конечно

[Archer]

Приятно было находить в поле кредитной карты "казябазяшные кракозюбли" или в поле где предполагалось наличие телефона интересные слова на любых из 20-ти языков.Ну про 50% полей с очень нужным значением NULL - я просто молчу.

Jes сидит почитывает, а сам небось вспоминает испанеров незлым и громким словом.

Ему наверное ещё сейчас при слове миграция икается и хочется немедленно выпить ... литр.... воТки.

 

Ха... напомни как-нибудь на пиве, чтобы я рассказал, как мы в Slovak Telekom делали миграцию из FoxPro (25 инстанций, иногда пересекающихся местами) в Oracle. Твои испанцы святые люди по сравнению с двумя генерациями словацких пользователей

[jes]

Ясен пень Че тут спорить - в базе конечно

Каждый кулик свое болото хвалит...

Я после _таких_ БД, вернее суппорта ДБ, побоюсь туда класть что-либо, просрут. А вы логику туда вставлять.

ЛОЛ, миграция, последний тестинг и вуаля, пол базы пустро, типа ДБА апдейт накатил на ДБ после миграции... часть данных в релиз ушло почти в слепую

[alp]

Так если бардак, так какая разница где он?

[jes]

Бардак в ДБ опаснее

В апликации трункейт не сделаешь

[Yevgen35]

Типа извечный спор, где логику держать, на уровне ДБ или на уровне аппликации...

Безсмысленно

До тех пор пока тебя после аудита не поставят "в позу", ну ты знаешь как она называется.

[maxicus]

О какая обширная тема.

Тут и мысораклова война, и тригеровалидаторы против ui, и чего должны делать дба, и у кого руки кривы при архитектурировании. Не остались в стороне даже getdate-еры в 3 поля, да еще и про SimpleDB проговорились.

 

Столько религиозных элементов и все в одном топике, во как накипело то в умах, нагретых майским солнцем .

Тут если не закончить пивом - будет обязательно кровь

 

Аж мушкетерпопкорн закончился пока прочел

[Yevgen35]

Почему сразу война?

 

Или ты предлагаешь высказываться политкорректно?

Так мы вроде не на презентации брендов.

[maxicus]

Не хотелось бы нарушать удовольствие от созерцания столь обширного поля боев без правил

Но патамуша. в контексте того с чего началось - утилитки для затаскивания каких-то левых данных спор о таких высоких вещах возможен только в виде религиозной войны

 

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

Тут же главным является куча деталей, которые никак тут не описаны. Бывает и mysql, в т.ч. легкий кластер на нем - лучшее решение чем всякие крутые БД, и кривая в внешнего взгляда архитектура оказывается на деле вовсе не такой. Я например частенько нарушаю нормализацию данных в тонких местах в целях ускромения конкретных тонких запросов жизненно важных для бизнес-проецесса, исключения deadlock-ов, намеренно делая гадости с точки зрения девственной академической БД-науки.

Да и вообще в первую очередь решает дело уже имеющийся опыт работающей группы.

 

Че хаять то дом за то, что у него на входной двери снаружи крюк приделан - одежду вешать неудобно.

Может его для другого нежели одежды удобней использовать

[Yevgen35]

Не хотелось бы нарушать удовольствие от созерцания столь обширного поля боев без правил

Но патамуша. в контексте того с чего началось - утилитки для затаскивания каких-то левых данных спор о таких высоких вещах возможен только в виде религиозной войны

А что дружеские подколы не могут присутствовать вместо "религиозной войны"?

 

 

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

На здоровье.

Только давай не путать денормализацию данных и целостностью данных.

Я полагаю это разные вещи.

Денормализацию можно и нужно реализовывать, но не в ущерб целостности(чистоты) данных внутри БД.