PostgreSQL 9.2

Как правило, декларативщина ограничивается внешними ключами и енумами.

откуда возьмутся ошибки в целостности?

Самоуверенные руби-хипстеры наделают.

Нет.. элементарными правилами active_record они сводятся на нет.

в которых тебе тоже придется прописывать таблицы, индексы и пр.

Ничего такого, что может усложнить переносимость не нужно.

элементарными правилами active_record они сводятся на нет.

Я давно уже не верю в сказки.

в которых тебе тоже придется прописывать таблицы, индексы и пр.

Ничего такого, что может усложнить переносимость не нужно.

Во-первых, ты приписал мне чужую цитату; во-вторых, в соседнем топике ты бодро вещал о том, что на продакшен-сервер нужно деплоить среду с машины разработчика, так что не тебе говорить о переносимости.

Так несколько мест (в приложении и в БД) как раз минус.

Императивно задавать ограничения в приложении — лишнее. Но даже если сделал и облажался — база тебя поправит.

минус переносимость

Это как «если я буду писать гуй на Qt, я потеряю переносимость на gtk или curses»?

минус гибкость (я вообще могу хранить данные в разных БД)

«Я вообще могу их использовать одновременно: мотив и кьюти».

Чем же так плохо «тупое хранилище»?

Отсутствием мозгов?

откуда возьмутся ошибки в целостности?

Из клиентского приложения, которое явно не будет дублировать все ухищрения нормальной RDBMS по сохранению этой целостности. Ибо долго и дорого писать постгрес ещё раз.

Это я ответил двум авторам в одном посте (простите). Во вторых то вещал не я. Но к данному спору это не относится)

то вещал не я.

Ну как же...

Касаемо версий самого руби, лучше разрабатывать и развертывать на одной ветке (1.8/1.9)"

это к вопросу о переносимости между ветками Руби

Далее в корне проекта есть Gemfile, в котором прописаны необходимые либы (можно с версиями) http://gembundler.com/

bundle install

И все поставилось, включая зависимости

это насчет среды разработчика в продакшен.

Но к данному спору это не относится)

Очень даже относится. Показывает, что твоя забота о переносимости 1) несколько односторонняя; 2) не поддержана стилем разработки.

база тебя поправит.

Т.е. парсить ответы БД.. ну-ну.

Это как «если я буду писать гуй на Qt, я потеряю переносимость на gtk или curses»

Ты так говоришь как будто это не правда) Написал на Qt - работает только там, где есть qt. И ничерта не работает там, где qt нет - большой минус для твоего клиента. Для клиентов переносимость куда важнее, тем для серверных приложений, пример явно не в твою пользу :)

«Я вообще могу их использовать одновременно: мотив и кьюти».

webkit(qt) + gtk = cromium, и что?

Отсутствием мозгов?

Т.е. в умном хранилище есть мозги.. прям начало конца света.

ухищрения

подробнее

webkit(qt)

Apple в курсе?

Ну разрабатывать на одной, а запускать на другой, это... странно. Руби 1.9 и 1.8 не полностью совместимы, это известно.

Показывает, что твоя забота о переносимости 1) несколько односторонняя; 2) не поддержана стилем разработки.

Я могу использовать другую реализацию ruby в рамках одной ветки, jruby, rubinius. Так что тут все норм.

Это опять же к теме не относится. Очевидно, что ноги растут из qt. А суть в том, что webkit уж точно gtk+, но работают вместе.

* webkit уж точно НЕ gtk+, но работают вместе.

Используют webkit совместно с разными gui, на разных платформах. Т.е. у WebKit, явно есть абстракция от gui, сродни (идеологически) ORM от БД. Так что ваши примеры, вам же в минус.

база тебя поправит.

Т.е. парсить ответы БД.. ну-ну.

Что за странная идея - парсить ответы? Их нужно читать (человеку) и исправлять ошибки в коде.

Ну разрабатывать на одной, а запускать на другой, это... странно.

А разрабатывать на одном SQL-сервере, а запускать на другом - это не странно?

Я могу использовать другую реализацию ruby в рамках одной ветки, jruby, rubinius. Так что тут все норм.

То есть разрабатывать на MRI и запускать результат на JRuby? «Hitting a C library which is not thread-safe will obviously not work. MRI not having real native threads (or native threads+GIL) will not blow up. We will» - при переходе проявятся латентные баги.

Их нужно читать (человеку) и исправлять ошибки в коде.

Т.е. возвращаемся к тому, что мне нужно все-таки предотвращать ошибки при запросах к БД.. ок.

проверки «от трех до пяти» нахрен не сдались в БД

не может повлиять на целостность данных, так зачем тогда?

А разрабатывать на одном SQL-сервере, а запускать на другом - это не странно.
То есть разрабатывать на MRI и запускать результат на JRuby?

Мало ли, но есть возможность.

Пример: Мы использовали mysql, потому, почему используют mysql. Внезапно нам потребовалась поддержка пространственных данных, а у postgres есть отличное расширение PostGis. Вот и повод перейти.

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

Т.е. возвращаемся к тому, что мне нужно все-таки предотвращать ошибки при запросах к БД.. ок.

ЩИТО? Мы возвращаемся к тому, что ошибка обнаружена при помощи контроля целостности на уровне СУБД.

То есть разрабатывать на MRI и запускать результат на JRuby?

Мало ли, но есть возможность.

Есть возможность огрести от этого ошибок.

Мы использовали mysql, потому, почему используют mysql. Внезапно нам потребовалась поддержка пространственных данных, а у postgres есть отличное расширение

И контроль целостности на уровне СУБД мешает этому... как именно?

Ах да... ты потеряешь переносимость - тебя это ВНЕЗАПНО перестало волновать?

Думаешь я не смогу предложить 10000 примеров -_-

(пожимая плечами) Ты даже не понимаешь, что твои примеры нерелевантны. Ты дай примеры того, как контроль целостности затрудняет переход на другую СУБД.

Очевидно, что ноги растут из qt.

что не означает, что webkit хоть как то связан с Qt, кроме как исторически

Используют webkit совместно с разными gui, на разных платформах. Т.е. у WebKit, явно есть абстракция от gui, сродни (идеологически) ORM от БД.
Так что ваши примеры, вам же в минус.

тебе уже говорили - отвечай автору комментария

Ты дай примеры того, как контроль целостности затрудняет переход на другую СУБД.

Да сказано уже было по этому поводу.

Потому что приложение это может сделать проще и гибче. Хватит уже логику пихать в БД, не нужна она там.

Ты дай примеры того, как контроль целостности затрудняет переход на другую СУБД.

Да сказано уже было по этому поводу.

Потому что приложение это может сделать проще и гибче. Хватит уже логику пихать в БД, не нужна она там.

Это было сказано по другому поводу - о конструировании приложений. А ты сказал, что страдает переносимость (между серверами СУБД, как я понял). Примеры будут?

Помоему это очевидно. Если у меня связность записей по ключам отслеживается в БД (это тривиальная задача), а валидность полей в записях в приложении, то зачем мне переносить это еще и в БД. Ведь очевидно при переносе необходимо переписать логику созданную в БД на новую платформу, а это влечет:

- написание кода

- отладку

- тестирование

Все это специфично для каждой платформы, и отнимает время. Чтобы это обосновать нужен профит, иначе зачем.

очевидно при переносе необходимо переписать логику созданную в БД на новую платформу

«Очевидно»? То есть примера того, как проверка целостности на уровне СУБД затрудняет переносимость между серверами СУБД, я не дождусь. Какая неожиданность.

Собственно как и я не дождался примера необходимости валидации всех полей на уровне БД.

Но наверное логика должна быть: «<что-то> полезно для <чего-то>, следовательно использую», а не «использую <что-то>, может пригодится..», нет?)

Т.е. парсить ответы БД.. ну-ну.

Обрабатывать исключения.

Собственно как и я не дождался примера необходимости валидации всех полей на уровне БД.

Умные дядьки придумали C в ACID, только вас это не касается, пишите как нравится. Обычно подобные товарищи также любят дискутировать по поводу нужности ВО для рубки бабла на поприще веба и прочего программизма.

Да сколько можно писать сообщения типа «умные дядьки придумали», я это перевожу «следовать идеологии не понимая ее», и в подтверждение замечу, что такие сообщения никогда не подкрепляются сколько-нибудь жизненными примерами: «кто-то там что-то сказал, кто-то там что-то придумал».

Вообще я готов сделать шаг назад и просто признать что можно разрабатывать и так и так. Т.е. кто-то привык слабо зависеть от платформы, бд и т.п., т.е. разрабатывать «гибко», отдавая приоритет приложению. Кто-то привык углубляться во взятую платформу, забивать логику в БД, оставлять приложению небольшую часть функционала. Я думаю оба подхода применимы. Но етм, не в двух же местах писать логику!

Императивно задавать ограничения в приложении — лишнее.

Почему ограничения нельзя задать декларативно?

У меня вон рядом есть человек, который постоянно заявляет: «чем меньше оставляешь свободы разработчикам сервера приложений, больше логики утягиваешь к себе в базу, тем легче поддерживать /решение целиком/».

Дай угадаю, у него теплое место и он не хочет чтобы его уволили?

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

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

Оставляя проверку целостности (хотя «целостностью» это назвать сложно, ввод пользователя приходится валидировать в любом случае, зачем это тащить еще и в базу, бред) за приложением, повелители баз автоматом перестают быть нужными и это прекрасно.

А вам нужен какой пример? Чтобы нельзя было написать ограничения в приложении, а только на БД? Так можно накодить что угодно при некоторой сноровке, и даже без БД можно обойтись. Только зачем это делать каждый раз?

Ладно, пример: несколько таблиц со связями один-ко-многим. Организуйте каскадное удаление записей, соблюдение связности а также уникальность на первичных ключах (или как оно у вас в приложении будет выглядеть), и все это в многопользовательской среде.

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

Так это у вас в архитектуре бардак. И в предприятии - что стенд неактуальный. Не надо валить с больной головы на здоровую.

повелители баз автоматом перестают быть нужными и это прекрасно

Скажу вам по-секрету, «повелителям баз» и без вашей целосности работы хватает, и лазить в ваших схемах особой радости тоже нет. Зато - ваш же пример - стенд держать в актуальном состоянии - куда вы без них?

Т.е. парсить ответы БД.. ну-ну.

Также, как «парсить ответы libc», «парсить ответы gem-а», you name it…

Хорошего разработчика можно вычислить уже хотя бы по тому, как он обрабатывает ответы close(2) в тестовом задании.

Написал на Qt - работает только там, где есть qt.

Именно так, и ничего удивительного. Для любителя всяких камушков: написал на RoR, а на Sinatra, сука, не работает. :( Хотя это что, оно даже при смене минорной версии Ruby поломаться может, про совместимость между 1.8 и 1.9 вообще молчу. И эти люди будут осуждать ковыряние в носу…

Т.е. возвращаемся к тому, что мне нужно все-таки предотвращать ошибки при запросах к БД..

Ты понимаешь, что COMMIT может завершиться неудачно по многим причинам?

Мы использовали mysql … Внезапно нам потребовалась … у postgres есть

Я опущу идиотизм ситуации, но /как/ здесь мешает контроль целостности?

Ведь очевидно при переносе необходимо переписать логику созданную в БД на новую платформу

Очевидно, что схему надо как минимум проверить и оттестировать на новой платформе в любом случае.

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

Элементарно http://guides.rubyonrails.org/association_basics.html#has_and_belongs_to_many...

все это в многопользовательской среде

галактика опасностей..

Ты понимаешь, что COMMIT может завершиться неудачно по многим причинам?

Еще одна галактика опасностей..

схему надо как минимум проверить и оттестировать

bundle exec autotest А ты как проверишь?)

Зато - ваш же пример - стенд держать в актуальном состоянии - куда вы без них?

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

Дай угадаю, у него теплое место и он не хочет чтобы его уволили?

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

Угумс, а потом разбирайся что в хранимках, что в схеме, а что в приложении, причем на стенде всё по-другому…

Разруха не в клозетах, товарищ.

ввод пользователя приходится валидировать в любом случае, зачем это тащить еще и в базу, бред

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

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

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

Раньше поле Abc могло принимать значения только $1 < Abc < 10$, теперь $2 < Abc < 5$. Сколько данных в базе стали по меньшей мере неактуальными, а то и приходящими к неочевидным ошибкам в логике?

Или кому-то хочется на каждый чих переписывать и деплоить новую версию клиента?

Б-г-г. Так бы сразу и сказал, формошлепщики придумали себе проблемы и героически их решают.

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

Примерчик давай, ты уже на потолок лезешь.

Сколько данных в базе стали по меньшей мере неактуальными, а то и приходящими к неочевидным ошибкам в логике?

Да ты упоролся, каким образом база в этом случае поможет? Что она сделает с существующими данными?

эм.. смотрю ты решил тут побредить)

написал на RoR, а на Sinatra, сука, не работает

И хотя я понимаю что ты пытался сказать, но примеры ты привел очень неудачные)) Что ror, что sinatra, это rack приложения. Что ror, что sinatra будут работать и на 1.9, и на 1.8. Кстати, у тебя при переходе с 8.4 на 9.2 все норм будет, да? А с 9.2 на 8.4? (не спрашивай зачем, я же не спрашиваю).

Именно так, и ничего удивительного.

Ничего хорошего, лучше бы у тебя была реализация под разные либы, а для этого нужна некая абстракция логики клиента от его гуи (я об этом уже говорил). Абстракции это хорошо. У тебя нет доводов против абстракции, а ORM это абстракция.

формошлепщики придумали себе проблемы и героически их решают.

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

каким образом база в этом случае поможет?

ERROR: check constraint «_range_check» is violated by some row

Что она сделает с существующими данными?

В том-то и дело, что и данные сохранит, и ногу отстрелить не даст. Это задача человека: решить, как поступить с данными, которые не удовлетворяют вновь появившимся ограничениям.

Что ror, что sinatra, это rack приложения. Что ror, что sinatra будут работать и на 1.9, и на 1.8.

Что mysql, что db2 — это rdbms. Что mysql, что db2 будут работать и на C, и на perl. А сказать-то чего хотел?

Кстати, у тебя при переходе…

У меня при переходе будет предварительный анализ, собственно переход, тесты на возможные регрессии и так далее, как и положено в нормальном процессе разработки. Какая-то абстрактная «переносимость» нужна тебе, а не мне. Кстати, так и не услышал, чем твоей «переносимости» мешает проверка целостности данных.

Сам проблему придумал, сам же ее и решил.

Элементарно ...

Ок, магия руби делает вака-вака и все работает.

галактика опасностей..

Это такой универсальный ответ на все вопросы?

Да никто не отрицает этот твой /анализ/. Но у меня при переходе окажется ~0-5% тестов невалидными. А тебе придется полностью переписать логику БД на новую платформу. Сколько у тебя уйдет человеко часов?

так и не услышал, чем твоей «переносимости» мешает проверка целостности данных.

Да хорош тормозить. Как полная завязка на одну БД мешает гибкой замене этой БД в случае необходимости, использованию дополнительных платформ типа redis, mongodb. Прямым образом я полагаю. Одно дело БД - хранилище, другое дело БД - модель.

Какая-то абстрактная «переносимость»

Тебе нужна какая-то абстрактная «целостность данных». Мои данные вполне целостные без дополнительных хранимых процедур.

Ты сейчас говоришь с позиции разработчика, я - с позиции сопровождающего твой продукт. Deployment and maintenance, если будет угодно. И все, что я хочу сказать - что твое удобство превращается в мою и security отдела головную боль.

Это такой универсальный ответ на все вопросы?

Проблемы чрезмерно абстрактны, что еще ответить.