Не БД

http://blog.8thlight.com/uncle-bob/2012/05/15/NODB.html
  • Перевод
Автор рассказывает о перипетиях пивоваров, производителей СУБД, себя и кратко о том как правильно проектировать приложения. Мне показалась полезной поучительная часть статьи.

В Соединённых Штатах в 1920х годах производство, продажа и импорт алкогольных напитков был запрещён конституционной поправкой. Поправка была отменена спустя 13 лет. За время этого запрета пивная отрасль умерла.

В 1933, когда запрет был снят, несколько зерновых гигантов стали варить пиво. Они полностью монополизировали рынок. И в течении почти 50 лет мы в Штатах пили эту газированную мочу и называли её «пиво». Единственным способом терпеть этот вкус — было пить его очень холодным.

Будучи в 60х подростком, я никогда не понимал его привлекательности. Почему пиво? Это же бледно-жёлтая, противная жидкость получаемая из мочи больных хряков. И я не мог найти ни одного веского плюса.

В 1984 я отправился в Англию, и шоры упали с моих глаз. Наконец я понял. Я впервые попробовал пиво и оно оказалось хорошо.

С тех пор ситуация с пивом в США значительно улучшилась. Новые пивоваренные компании растут по всей стране как грибы, и в большинстве случаев пиво, которое они делают, действительно очень хорошее. У нас нет ничего столь прекрасного как биттер (горькое охмелённое пиво), но мы догоняем.

В 80х несколько больших компаний своими базами данных монополизировали рынок. Они сделали это насаждая страх, неуверенность и сомнения среди менеджеров и маркетологов. Слово «реляционный» стало синонимом «качественный», и любой другой способ хранения данных стал запретным.

В те времена я был ведущим разработчиком. Наша система измеряла качество линий связи Т1. Наша модель данных была относительно проста, и мы хранили данные в простых файлах. Это работало нормально.

Но наш маркетолог продолжал говорить нам, что мы должны использовать реляционную базу данных. Он сказал, что клиентам она потребуется. Мне казалось что это странное желание, поскольку тогда мне ещё не продали ни одной системы, и ни один покупатель ни разу не интересовался нашим способом хранения данных. Простые файлы были под запретом.

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

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

Угу, Конечно. Точно. Железячник без реального опыта программирования собирался «помочь» мне управлять командой. И какой, вы думаете, был первый пункт? Почему бы не использовать реляционную базу данных в нашей системе!

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

Я наблюдал за рынком реляционных баз данных в 90х. Я видел как все другие технологии хранения данных, такие как объектные базы данных и базы данных на B деревьях, вырождались и умирали. Как пивовары в 20х. К концу 90х уцелели только гиганты.

Эти гиганты гнали волну. Они были богами. Они правили. Во время пузыря доткомов, один из них набрался наглости запустить рекламу на телевидении, в которой заявлялось, что их система была «силой которая управляла интернетом»(the power that drove the internet). Это напомнило мне слоган пива из 70х — «Мну должен зохватить весь кайф, какой смогу». О боже.

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

Я был свидетелем возникновения новой должности. Администраторы баз данных! Простым программистам нельзя доверять данные — так гласила маркетинговая чушь. Данные слишком ценны, слишком хрупки, слишком легко повреждаются этой не обученной деревенщиной. Нам нужны специальные люди для управления данными. Люди, натренированные поставщиками СУБД. Люди, которые будут оберегать и пропагандировать послания гигантов СУБД рынку: «Базы данных это основа. Основа системы, основа предприятия, основа мира и самой вселенной. БУ-ГО-ГА-ГА-ГА-ГА!!!»

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

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

А потом, в первом десятилетии 21го века, запрет был снят, и было рождено движение NOSQL. Я считал это каким-то чудом, сияющим светом озарения. Наконец кто-то осознал, что могут быть в мире системы, которым не нужны большие, жирные, медленные, дорогие, пожирающие память реляционные базы данных!

Я с умилением смотрел, как BigTable, Mongo, CouchDB и другие милые маленькие системы баз данных начали расти, прямо как маленькие пивоварни в 80х. Пиво вернулось! И оно становится вкусным.

Но потом я приметил кое-что. Некоторые системы, использующие эти милые, простые, изящные не реляционные базы данных, были спроектированы вокруг баз данных. Базы данных, завёрнутые в сверкающие новизной фрэймворки, по-прежнему в основе! Это в мозгах проектировщиков аукается ядовитая реляционная рекламная чушь. Они по прежнему делают роковую ошибку.

«Стойте!» — Я закричал. — «Стойте! Вы не понимаете. Вы не понимаете.» Но импульс был слишком велик. Возникла огромная плеяда фреймворков, она обрушилась на нашу отрасль и овладела миром. Эти фреймворки охватили базы данных и бились за захват и удержание ядра вашего приложения. Они были призваны управлять и укращять базы данных. Даже утверждалось, что они могут превратить реляционную базу данных в базу данных NoSQL. И фреймворки громогласно кричали на весь мир: «Положись на меня и я сделаю тебя свободным!».

Название этой статьи «Не БД». Возможно после этих разглагольствований вы получили намёк, почему я назвал её так.

Основа вашего приложения — не база данных. И не один или несколько фреймворков, которые вы можете использовать. Основа вашего приложения — сценарии его использования.

Я с ума схожу, когда слышу, как разработчик описывает свой проект в стиле: «Tomcat со Spring'ом и Hibernate на Oracle'е». Сама формулировка ставит фреймворки и базы данных во главу угла.

Как Вы думаете, на что похожа архитектура этой системы? Думаете,
вы найдёте сценарии использования в основе проектирования? Или Вы обнаружите, что исходный код подогнан, чтобы лучше вписываться в модель фреймворка? Заметите ли вы, что бизнес объекты подозрительно напоминают строчки таблиц? Замарает ли все схема данных и фреймворк?

Вот как должно выглядеть приложение. Сценарии использования должны быть самыми важными и наиболее заметными архитектурными объектами. Сценарии использования — это основа. Всегда! Базы данных и фреймворки — детали! Вам не нужно выбирать их с самого начала. Вы можете отложить их на потом, до тех пор, пока все сценарии использования и бизнес логика не будут сформулированы, записаны и проверены.

Когда лучше определиться с моделью данных? Когда вы знаете, какие есть объекты данных, как они связаны и как они используются. Когда вы это узнаете? Когда все сценарии использования и бизнес правила записаны и проверены. К тому моменту вы определились со всеми запросами, отношениями и элементами данных и вы сможете построить модель данных, которая отлично подойдёт к базе данных.

Что-то измениться если вы используете NoSQL базу данных? Конечно, нет! Вы по прежнему сосредоточены на том, чтобы сценарии использования были записаны и проверены, не обращая внимание на тип базы данных перед тем, как даже подумать о базе данных.

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

Впереди интересное время. Время, когда запрет на различные технологии хранения снят, и мы можем свободно экспериментировать со множеством новых подходов. Но и во время игры с CouchDB, Mongo и BigTable не забывайте: База данных это просто компонент, который не требует немедленных решений.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 175
  • +3
    Разделите пожалуйста абзацы, сейчас все слитно и тяжело читать. Спасибо за ваш перевод :)
    • +1
      Разделил. Рад что понравилось.
    • 0
      Только вчера обсуждали с коллегой, что программист должен быть полностью абстрагирован от БД. SQL, NOSQL — на уровне приложения это не должно играть абсолютно никакой роли. ОРМ (ну или у кого там что в зависимости от парадигмы), должна быть гибкой и позволять безболезнено сменить используемую БД на любом этапе разработки. Звучит конечно утопично, но имхо в будущем так и будет

      Перевод очень качественный, спасибо.
      • +31
        ОРМ (ну или у кого там что в зависимости от парадигмы), должна быть гибкой и позволять безболезнено сменить используемую БД на любом этапе разработки. Звучит конечно утопично, но имхо в будущем так и будет

        Я такие же слова много раз встречал в отношении ООП «можно безболезненно заменить одно на другое и всё будет работать». Это не работает, моё личное мнение. Всегда нужно держать в уме весь стек используемых технологий, иначе случаются казусы и глюки.
        • +5
          Полностью согласен. Кроме казусов и глюков еще чаще бывает неэффективное использование — например многие БД имеют полезные особенности, не доступные через слой абстракции.

          Ну и стоит вспомнить еще и о законе текучих абстракций:

          www.joelonsoftware.com/articles/LeakyAbstractions.html
          • +1
            Я и сказал в конце коммента
            >Звучит конечно утопично, но имхо в будущем так и будет
            • НЛО прилетело и опубликовало эту надпись здесь
              • –1
                Как апи может не зависеть от имплементации? Они непосредственно связаны, и API предоставляет доступ к имплементации. Это фантик над ней. И этот фантик может подходить к другим конфетам, а может и не подходить. Так вот тот который подходит — это обычный фантик, им удобно оборачивать разные конфеты, а если фантик уникален — то им обернешь только один вид конфеты, но зато КАК!

                Это компромисс между перфомансом, удобством и доп фичами в случае специализированного API, и обобщенностью и заменяемостью в случае обобщенного.

                Не нужно говорить хорошая\плохая. В жизни почти везде компромиссы. Полярность — это чаще следствие максимализма.
                • НЛО прилетело и опубликовало эту надпись здесь
                  • 0
                    Как пример — посмотрите на статью Спольски про текущие абстракции
            • +3
              но имхо в будущем так и будет

              В будущем терабайты данных будут хранится в памяти, а сбрасывание их на диск будет занимать сотые доли секунды. :)
              • +3
                Насчёт последнего хочу вас сильно разочаровать. Скорость СХД растёт много медленее, чем ёмкость. Если в 2000ых нормой для HDD было 30Мб/с, то сейчас — 130. На SSD — около 270. Т.е. даже на порядок не выросла. Ёмкость с тех пор выросла примерно на 2 порядка.
                • +1
                  Зато появились системы вроде zfs, которые умеют работать с только измененными участками данных. Вероятно, схожие алгоритмы найдут свое применение и для работы с данными в памятью и параллельном сохранении на диск.
                  • 0
                    Будет все проще! Будет кэш процессора и просто память. Та которая рядом и та которая далеко. В нее пишешь и не думаешь, что еще нужно потом скинуть в долговременную память.

                    Не будет оперативной и долговременной памяти. Только просто память!
                    • 0
                      ну когда-то так и будет, но умное сбрасывание данных на диск появится гораздо раньше. Точнее, будет развиваться то, что уже есть
                      • 0
                        Лет восемь назад думал о том, что было бы неплохо скрестить оперативку с флешкой. Если на одном чипе, то сохранение памяти во флеш займет очень мало времени. Чуть ли не тригер возле тригера можно сделать.
                        Теоретически конечно… помню тогда интересовался этим, и что-то там мне показалось слабо реализуемым на уровне техпроцессов. Но уже восемь лет прошло…
                        • 0
                          А зачем это делать? Гебернейт уже давно есть, если сбрасывать на ssd то и будет примерно то, о чем вы говорите.
                          • 0
                            Восемь лет назад ssd еще не было.
                            Но не в этом суть — тут время в секундах измеряется. Это много.
                            За это время может потеряться питание, произойти глюк и т.п.
                            И делается процессором.
                            А это ненадежно надежно.
                            Он может зависнуть, остаться без питания и т.п.
                            • 0
                              Та было, просто называлось иначе и не в таком широком доступе было;)

                              Вопрос в том, как вы представляете себе дублирование оперативы на флешку. Она во-первых медленнее в разы, во вторых сдохнет быстро, если ее в схожем режиме с оперативой использовать
                              • 0
                                Оперативка, обычная DDR3 на два гигабайта… Внутри — 2гб озу и 2гб флеш.
                                Но только не так чтобы 8 чипов озу и 1 чип флеш, а именно восемь чипов общей памяти (ну или 16, не суть). Внутри каждого чипа есть оперуха и флеша.
                                Падает питание, подается команда «сохраняйся». И чип делает запись на флеш.
                                Поскольку тут доли секунды то хватит и конденсатора для питания.

                                Если сохраняться десять раз в день, то лет на тридцать должно хватить.
                                • 0
                                  Уверенны что доли секунды? Даже сейчас скорость записи на SSD не превышает 200-400МБ если рассматривать долговременную запись по всему объему. 2ГБ это 5-10с, при том что оператива сейчас в ходу от 16, если брать стационарные компьютеры. А тогда флеш была на порядки медленее.

                                  Эта задача решается гипернейтом (на рейд из sas дисков оно было бы быстро и 8 лет назад) + ups. Значительно дешевле и практичнее вашего решения.
                                  • 0
                                    Уверен.
                                    Я же говорю — НА ОДНОМ ЧИПЕ.
                                    Не нужно гонять по шине.
                                    В самом идеальном случае это будет один бит памяти, за ним один бит флешки.
                                    Т.е. выход тригера памяти идет на вход флешки… сразу, без шины.
                                    Т.е. вся память сохраняется ОДНОВРЕМЕННО, а не блоками.

                                    Понятно что в реалиях будет немного не так, ибо «служебная» логика вырастет в разы, но тем не менее близость носителей была бы очень быстрым решением.
                                    • 0
                                      В шину сейчас ничего и так не упирается — только в производительность самой флеш-памяти и алгоритмы контроллера (не производительность контроллера). И тут уже без разницы как близко вы разместите одну и вторую память. Запись в миллион потоков только понизит производительность, вместо повышения.

                                      И главное, чем ваше решение лучше обычного УПСа?
                                      • 0
                                        Преимущества я написал выше.

                                        За контроллером идет шина через которую он и работает с памятью.
                                        Поскольку запись последовательная, то мы имеем задержку. А если шины нет, и запись параллельная то скорость записи всей памяти равна скорости записи одного бита.
                                        • 0
                                          Во-первых, вы не понимаете, как работает флеш-память (любая память), если говорите о том, что параллельность увеличит производительность. Повторю: в шину и сейчас ничего не упирается.

                                          Во-вторых, любой современный ультрабук умеет мгновенно засывать при закрытии крышки и жить в таком режиме пару недель. Напряжение на память при этом подается, просыпается из такого режима за 2 секунды. Если батарея подходит к концу, то автоматиески идут гибернейт.

                                          В материнскую плату можно встроить аккумурятор от телефона, который будет весить как один из радиаторов, при этом, обеспечит возможность проработать в спящем режиме несколько часов и потом загибернейтиться, если с питанием таки все плохо.
                                          Технология уже есть (в последнем поколении ультрабуков), аккумулятор встроить не проблема, задача решается даже лучше, чем ваша (хоть вы и уверенны в бесконечной скорости флеш-памяти, на самом деле, это совсем не так), зачем городить огород?
                                          • 0
                                            Ну сейчас может и нет смысла. Единственное преимущество в том, что это было бы хардварное решение, которое более надежно. Ну в плане того что оно единое и без множества посредников.

                                            Я об этом вспомнил чисто в контексте того, что вполне может скорость вырости революционно. Я ж не предлагаю прямо бросаться это реализовывать. Просто как концепт озвучил в ответ на:
                                            ===
                                            Насчёт последнего хочу вас сильно разочаровать. Скорость СХД растёт много медленее, чем ёмкость. Если в 2000ых нормой для HDD было 30Мб/с, то сейчас — 130. На SSD — около 270. Т.е. даже на порядок не выросла. Ёмкость с тех пор выросла примерно на 2 порядка.
                                            ===
                                            • 0
                                              В вашем случае, вылетает флешк-модуль и под замену весь блок идет. К тому-же, аше решение такое-же хардварное, как и текущее в ультрабуках. И там как раз обошли ограничение в скорости СХД благодаря тому, что система может неделями в спящем режиме работать, этого хватит, чтобы на ленту оперативу сбросить.
                      • +1
                        Кэш процессора тут тоже лишний — будет просто БЫСТРАЯ ПАМЯТЬ :)
                        • 0
                          Не соглашусь. Все же будет память «рядом» и память «далеко». Та что «рядом» и есть кэш.
                        • 0
                          Отображение файлов на память есть и сейчас. Вопрос нужно ли все изменения в быстрой памяти дублировать в долговременную, а если не нужно, то как разделять в коде?
                          • 0
                            Сейчас RegMem-Cache-DRAM-HDD,
                            а будет нечто вроде RegMem-Cache-(MRAM|PRAM).

                            В коде на уровне ассемблера модель Cache программно недоступна (почти). Поэтому можно не задумываться как разделять в коде обращения в Cache и DRAM. Нужно лишь помнить о размере L1, L2, L3, DRAM и обрабатывать данные в соответствующем порядке и объеме.
                  • +14
                    Мне кажется, что автор писал не о том, чтобы абстрагироваться от БД, а вообще не рассматривать БД как обязательный элемент.

                    Например, большинство современных сайтов на которых есть только набор статических страниц зачем-то тянут за собой БД. Там как раз не нужно ни хитрых выборок, ни отчетов. Прекрасно можно обойтись просто файловой системой.

                    На самом деле в таких случаях не нужно даже PHP/Ruby/Python для обработки каждого запроса. Можно все так же удобно сделать через генераторы вроде Jekyll. Но это уже оффтоп, конечно.
                    • 0
                      Именно так!
                      Если начать не с технологии хранения — можно всё сделать и оптимальнее и, что важнее, правильнее.
                      • +10
                        Можно обойтись, написав строчек 200 сохранения, загрузки, валидации, управления безопасностью.

                        А можно просто подключить компонент и реализовать это за 5 строк. Надежно, быстро, безопасно. Да, не очень оптимально. Да, не самое рационально по CPU/RAM/HDD. Зато очень рационально по человеко-часам чтения и написания софта.

                        Время человека стоит несоизмеримо дороже времени процессора.
                        • 0
                          Разумеется, писать вручную часто дольше чем использовать готовый компонент. Всегда нужен какой-то компромисс.

                          Но вы смотрели, нету ли каких-то уже готовых решений которые в некоторых задачах могут заменить БД не уменьшив ни эффективности разработки ни эффективности решения?

                          Я, например, упоминал Jekyll. На нем построены GitHub Pages, которыми пользуются достаточно многие, для сайтов проектов, блогов и т.п. И там совсем не надо писать 200 строк сохранение/загрузки. Более того, там не надо писать даже 5 строк. Есть еще некоторое количество менее известных утилит, делающих приблизительно то же самое.

                          Но, конечно, иногда необходим чтобы клиент мог редактировать контент в браузере и все такое. Для таких случае есть например pulsecms.com/

                          P.S. Действительно ли сохранение/загрузка файла на диск требует в 40 раз больше кода, чем выполнение запроса к БД?

                          Ruby:

                          File.read("content/#{id}")
                          
                          File.open("content/#{id}", "w") {|f| f.write data}
                          


                          PHP:

                          $fh = fopen("content/".$id, 'w');
                          fwrite($fh, $data);
                          fclose($fh);
                          


                          Плюс — не надо подсоединяться к БД, создавать там схему и все такое.
                          • +7
                            Добавьте: десериализацию (редко когда всего одно поле данных, скорее всего хранится какая-то структура), защиту от параллельной записи, проверку на валидность имени файла (чтобы не читать /etc/passwd), защиту от одновременной чтения и записи.

                            Пускай не 200, но если говорить про блокировки одновременного доступа, то строк будет явно больше чем подключение к БД.

                            И дело даже не в строках: диска-то на лишних 500 байт не жалко. Дело в том, что чем больше кода, тем больше багов. А это уже важнее.
                            • +3
                              Да, безусловно когда количество таких моментов растет, готовое решение будет явно лучше. Возможно, что это будет именно БД.

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

                              Все остальные проблемы (валидация, квотирование, сериализация) решаются или библиотекой работы с БД или кодом в вашем приложении, который с ней взаимодействует.

                              Точно так же вы можете решать их стандартными средствами и без БД. Например, сериализуя данные в JSON/YAML, для чего сейчас практически везде есть стандартные средства.

                              Много кода это очевидно хуже чем мало, да. Поэтому, где это возможно лучше использовать готовые средства. Но БД не является единственным таким средством. Например, в руби есть такая штука как PStore, он кстати и проблемы одновременного доступа решает используя атомарные переименования.

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

                              Но, если вернуться к началу ветки — я все-таки писал о «большинстве современных сайтов на которых есть только набор статических страниц». Мне кажется, что 90% их потребностей покрывают готовые средства вроде Jekyll или PulseCms. И писать строки кода, решающие описанные проблемы там не нужно ни при использовании БД ни без нее.

                              Я не являюсь противником использования БД. Они крайне полезны во многих случаях. Но мне кажется, что стоит использовать простые решения когда задача это позволяет.
                              • +3
                                Вообще говоря хранение данных это только половина того, что делает система управления БД. Вторая половина ( не менее важная чем первая ) это поиск данных.

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

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

                                Далее перед нами встанет вопрос поиска. Например, нам нужно реализовать поиск информации по заданным полям на странице. Для того чтобы это работало быстро — нам нужено будет реализовать индексирование по полям. Так же нужно будет реализовать обновление индекса при обновлении информации страниц и тд…

                                В конечном итоге мы получим некое подобие системы управления БД встроенной в нашу систему.
                                • +5
                                  Есть такая система, называется докувики.
                                  Полноценный вики-движок, полностью на файлах.
                                  dokuwiki.ru/
                                  • +1
                                    Про сериализацию я уже писал.

                                    По поводу поиска — если сценарии использования вашего приложения включают поиск по полям — используйте те средства, которые позволяют его просто реализовать. Например, БД. Или Сфинкс. Или ДокуВики (интересно как там это сделано, не знал про нее).

                                    Если не включают — вы можете использовать что-то более простое.

                                    В случае «сайтов на которых есть только набор статических страниц», пользователю не нужен поиск по полям, ему нужен поиск страниц — с этим прекрасно справляется какой-нибудь Google Site Search.

                                    Разумеется, если вы пишите сайт магазина или социальную сеть — хранение в файлах это совсем не самое лучшее решение, и я не знаю как тут обойтись без БД.

                                    Просто используйте те инструменты, которые подходят к вашей конкретной задаче.
                                  • 0
                                    А унификация?
                                    Вот зачем мне поддерживать несколько разрозненных решений?
                                    Зачем мне для сложных задач держать SQL-решение, для тяжелых баз noSQL а для простых и легких файловую базу?
                                    Если у меня есть решение которое работает на простых задачах, то зачем мне делать другое? Просто потому что «так лучше»?
                                    Вот серьезно. Практическое преимущество какое? Не нужно заморачиваться с настройками базы при установке? Ну так с правами на запись забадаешься… Скорость? Да пофиг на нее в маленьких задачах)

                                    Ну как компромисс можно конечно sqlite брать, но в статье вроде как не об этом.
                                  • +3
                                    Резюмируя, можно сказать, что в современных СУБД важна не сама БД, а обвязка, которая серьезно упрощает процесс работы с данными.
                                  • 0
                                    Ваш вариант отлично работает для простых сайтов. Но вот когда вам нужно посмотреть страницы одного автора, которые были опубликованы между 20м числом предидущего месяца и 10м числом текущего отсортированы по количеству комментариев от большего до меньшего, то вместо соединения с базой и несложного запроса вам нужно будет нагородить довольно много кода, не так ли?
                                    • +1
                                      Конечно. И я несколько раз уже написал об этой ветке.

                                      Инструмент нужно выбирать с соответствии с решаемыми задачами.
                                      • 0
                                        об этой ветке => об этом в этой ветке
                                    • 0
                                      Иногда использую в PHP:

                                      file_put_contents("content/{$id}", serialize($content));
                                      
                                      $content = unserialize(file_get_contents("content/{$id}"));
                                      


                                      На любителя можно использовать json_encode/json_decode или любой другой «сериализатор», например YAML или XML.
                                  • 0
                                    Неоднозначно.
                                    Недавно написал легкий движок файлообменника. Всего 20кб кода.
                                    Функционал простой как пять копеек — загрузил, скачал, копии, абузы, просмотр в зависимости от миме (т.е. видео значит смотрим онлайн-видео, аудио значит аудио, картинка значит картинка..), защита от хотлинка… В общем то и всё.
                                    Я решил написать его на файлах. Чистых файлах без ничего. Подумалось что информации у меня не много и не сильно она разнообразна… а базы под нагрузкой это специфика… Ну и отдельный файл для каждой записи мне показалось достаточно быстрым и защищенным от блокировок решением.

                                    В общем на практике структура «базы» менялась раз шесть, каждый раз вместо тривиальной одной строчки в ORM приходилось все перекручивать и принимать решения. Решения не сложные, после третьей переделки я все «запросы к базе» вынес в один файл, чтоб проще было, но тем не менее — это куча телодвижений, а задача простая.

                                    После этого я зарекся без готовых библиотек лезть в файловое хранение… Хотя в 2DO я себе записал сделать драйвер для своего ORM для хранения в файлах.
                                    • 0
                                      Я имел в виду в первую очередь блоги, сайты-визитки и прочее, где весь динамический функционал состоит максимум в использовании комментариев (которые сейчас все чаще подключаются на стороне клиента через внешний сервис).

                                      В таких случаях не нужно логики на сервере вообще, Apache/Nginx может отдавать просто статичные страницы, которые заранее подготовлены чем-то вроде Jekyll.

                                      А в вашем случае (когда пользователи как-то меняют содержимое) то или иное хранилище данных однозначно нужно, лучше использовать что-то готовое, например БД.
                                  • +3
                                    Нет, так нельзя. Если ОРМ позволяет сменить любую БД на любую другую, то фичи конкретных БД просто игнорируются.
                                    • +3
                                      Нет — если ОРМ умеет использовать фичи конкретных БД. А приложению, за слоем абстракции, будет без разницы как оно там устроено
                                      • –5
                                        Если ОРМ использует фичи конкретных БД, то это значит, что она прибита к этой БД гвоздями. И ни о каких сменах БД речь идти не может.

                                        Это в принципе общая проблема всех проксей.
                                        • +5
                                          Окей, а вам часто в реальных проектах приходилось переходить с одной СУБД на другую? Наверное, очень редко или вообще никогда. А часто нужно было поддерживать более, чем одну СУБД одновременно? Наверное, чуть чаще, но всё равно редко. А часто приходилось выдумывать костыли из-за того что гибкий ORM не предоставляет какой-то нативной возможности СУБД? Предполагаю, что бывало такое. Ну так в чём профит гибких ORM?
                                          • 0
                                            >Окей, а вам часто в реальных проектах приходилось переходить с одной СУБД на другую
                                            Нет это задача редкая.

                                            > часто нужно было поддерживать более, чем одну СУБД одновременно?
                                            Да, связка SQL+NOSQL имеет смысл в определенных ситуациях. Было бы просто офигенно работать с ними через единый объектный интерфейс.

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

                                            >Ну так в чём профит гибких ORM?
                                            Имхо за ними будущее. И в первом комменте, я говорил о будущем, а не о текущем состоянии дел (современные орм, чего греха таить, далеки от совершенства).

                                            Это нормальная тенденция в развитии технологий — по накоплению определенного стэка знаний, происходит разделение на более узкие специальности. Кто-то например пишет компиляторы, а кто то софт, который эти компиляторы будут собирать. То же станет и с БД, помяните мое слово — будут узкие специалисты, занимающиеся созданием ОРМ, и прикладные разработчики, использующие их.
                                            • 0
                                              Это нормальная тенденция в развитии технологий — по накоплению определенного стэка знаний, происходит разделение на более узкие специальности.

                                              Какое уж там разделение, если программисты не хотят понять необходимость наличия администраторов БД. Причём каждая СУБД это свой мир, свои правила, свои оптимизации и, чего уж там, хаки. Даже между двумя РСУБД столько отличий, что если в проекте используются несколько, лучше иметь несколько спциализированных АБД (либо одно Чака Норриса). Что уж говорить про различия между реляционными, объектными, иерархическими и прочими БД. А вы хотите это всё под одну гребёнку. Если уж будет разделение разработчиков, то разделятся именно по опыту работы с API разных БД.

                                              А то, что вы говорите, это ещё более утопично, чем сказать что в будущем html/css будет полностью семантическим.
                                              • 0
                                                Расскажите о том какие специфические вещи связанные с СУБД приходится использовать?
                                                Есть драйвер который выполняет основные действия, а дальше уже абстрактный слой…
                                                На практике сталкивался с тем, что лишь несколько узких мест нужно было вручную запрос написать для ускорения, и он уже потом при переносе мог вызвать или тормоза или отказ в работе если сильно специфичный был. Но это детали, и очень редкие.
                                              • +2
                                                Я, видимо, как-то неточно выразился.

                                                Я как раз против «гибких ORM» и считаю это чем-то типа premature optimization: эффективно(читай — с учётом конкретных особенностей и фич) базу надо использовать прямо сейчас, а гипотетические миграции с одной СУБД на другую то-ли будут то-ли нет. И, собственно, пытался показать, что совместить и то и другое(и эффективную работу с БД и абстрагирование от неё) не совсем возможно. Поэтому отказ от «лёгкости» — вовсе не блажь или там ошибки дизайна а сознательное решение.
                                              • +4
                                                С чего бы — конкретные интерфейсы для конкретных БД на уровне ОРМ + интерфейс уровня приложения
                                                • 0
                                                  С того-бы, что этот единый интерфейс, предоставляемый ОРМ будет реализовывать только пересечение функционалов этих самых БД. Т.е. мы вернулись к самому началу: фичи конкретных БД просто игнорируются.
                                                  • 0
                                                    Не факт, он может предоставлять и объединение функциональности. В реализациях где возможно будут использоваться фичи движка, где нет — «костыли».
                                                    • 0
                                                      Все нужное переносим в ORM, и если движок база не поддерживает возможность, то делаем в ORM то, что делали бы в логике программы.
                                                      К примеру — делаем в ИННО внешние ключи, а в майисам делаем эти функции кодом драйвера. В результате с точки зрения программиста разницы нет никакой.
                                          • +11
                                            Да мужик просто псих же.
                                            • 0
                                              В хорошем смысле? :)
                                              • +14
                                                Нет, я серьезно. Жуткий obsession на почве БД, как можно столько лет заниматься «предупреждениями и увещеваниями», и как можно не допускать компромиссов между скоростью разработки и используемой архитектурой приложения. Он не сильно-то лучше и объективнее своих ветряных противников, маркетологов от БД.
                                              • 0
                                                есть такие программисты-фанатики. вот он, по-моему, из их числа
                                              • +1
                                                Я по привычке всегда представляю архитектуру как тонкую прослойку между базой и пользователем, которая служит обычным предохранителем от нежелательного воздействия.

                                                Статься заставила задуматься, я не могу представить другого. Где почитать о разработке, которая не ставит БД в «серце системы»? Может автор прав?
                                                • 0
                                                  Да, ставить БД в основу основ при проектировании системы, с одной стороны — не хорошо. Но порой в базу данных и закладывается вся предметная область, так как это, скорее всего, это удобно.

                                                  С другой стороны правильнее проектировать систему исходя из подхода который был выбран. Выбираем ООП — мыслим в терминах объектов и классов, а дальше уже думаем где у нас будут данные храниться, и главное — как храниться.
                                                  • +2
                                                    Пользователь в данном случае кто?
                                                    Если клиентское приложение то возможно так и надо, если это именно пользователь то вы уж меня извините но софт пишется для пользователя а не для БД. Так что это бред как бы.

                                                    Есть некая задача которую надо решить. Решить ее надо удобно, чтобы пользователь сделал меньше кликов, увидел меньше окон и таки добился результатов. Это всё.

                                                    И я что-то не вижу тут в этой формулировке ни слова о данных. В целом я абсолютно согласен с автором статьи. Есть набор процессов, которые следует автоматизировать, и вот они во главе угла.
                                                    • 0
                                                      Я несознательно связал базы данных с web-приложениями… А так, у самого, большой проект на С++, который хранит данные в своем бинарном формате.
                                                    • +1
                                                      en.wikipedia.org/wiki/Domain-driven_design

                                                      и в догонку книжка по этой теме www.ozon.ru/context/detail/id/5497184/
                                                      • 0
                                                        Попробуйте представить, что ваше приложение живёт в оперативке вечно, объект, который вы создали никуда не исчезнет пока его явно не удалишь, память не ограничена, доступ произвольный и прочие идеальные штуки. Нужна вам будет в такой ситуации БД? А теперь рассматривайте БД лишь как контролируемый своп, в который неиспользуемая сейчас память выгружается, а когда нужно загружается.
                                                      • +6
                                                        Слава SQL-я пошатнется когда NoSQL решения смогут обеспечивать транзакционную целостность. Сейчас ни Mongo, ни CouchDB могут гарантировать лишь атомарность единичной операции.

                                                        Если же, например, у вас онлайн игра, где предмет передается от 1 персонажа другому, то ни одно NoSQL решение не может гарантировать что у вас исключена ситуация, когда предмет отобран от персонажа А, но не пришел к персонажу Б.

                                                        Для серьезных систем, особенно оперирующих деньгами и услугами, это критически важно.
                                                        • +1
                                                          OrientDB может. ACID транзакции у них заявлены.
                                                          • 0
                                                            Полностью согласен!
                                                            Надеюсь, недавно привлеченные инвестиции помогут Mongo реализовать транзакционность.
                                                            Хотя, если честно, написать очередь транзакций — это строчек 200 кода.
                                                            • +8
                                                              заставить эти транзакции работать также надёжно как в оракле — это 200 человеко-лет
                                                            • +10
                                                              Да при чём тут SQL или NoSQL. Да, NoSQL скоро подтянутся и будет в них всё, что есть в РСУБД: транзакционность, хранимые процедуры на JavaScript, блокировки разных уровней, разделение прав доступа, ссылочная целосность и всё прочее, чем обросли современные РСУБД. И какая тогда будет разница? Ну не будет SQL, будет свой API доступа к данным (пока же у документо-ориентированных БД нет и десятой доли возможностей доступа к данным, предоставляемых SQL). И опять разработчики взвоют, что им не дают конролировать данные. Как ювелир, который обрабатывает золото, преобразуя его в конечные изделия, но не имеет полного доступа к нему [золоту], так и программист только выполняет обработку данных и красиво отображает их на экране. Заказчикам в сотни раз важнее сами данные, чем процессы отображающие их на экране и позволяющие производить манипуляции с ними. Заказчики должны иметь резервные копии данных и контролировать процессы, которые могут привести к порче данных: пусть хоть сгорит сервер приложений и репозиторий исходных кодов, но если испортятся данные это практически крах бизнеса. А автору просто обидно, что крупные компании не верят в то, что он, великолепный программист, может сам безопасно хранить данные (и правильно делают).
                                                              • –1
                                                                Полностью согласен.

                                                                СУБД — лишь способ обеспечить надежное хранение данных. И покуда NoSQL не могут гарантировать надежность этого хранения, оно имеет лишь ограниченные возможности применения.

                                                                Посмотрю я на этого апологета NoSQL/файлов когда у него в системе, оперирующей деньгами, со счета одного абонента деньги снимутся, а на счет другого не придут. Как он будет выяснять что случилось и что он будет делать в этом случае.
                                                                • +1
                                                                  Многие современные NoSQL вполне успешно справляются с надёжным хранением данных и обеспечивают хорошую персистентность: тот же монго при должной настройке и конфигурации системы, редис и многие другие. Да, для финансовых приложений всё равно не очень годится. Другое дело, что подход-то не меняется — те же БД только в другой обёртке. Тот же отдельный уровень в приложении. Те же администраторы БД, ведь чтобы грамотно настроить MongoDB тоже нужен квалифицированный специалист. Да что уж там говорить — Java разработчики не очень-то хотят сами писать map/reduce функции. Хотя казалось бы — вот оно, NoSQL, теперь программисты сами будут управлять данным, складывать их как захочется и извлекать, а не тут то было — от нас, администраторов БД, вам ещё не скоро удастся избавится :)
                                                                  • +1
                                                                    Скорость MongoDB отчасти заслуга отсутствия транзакций. Посылаешь данные, монга их принимает и ставит в очередь. Никто не может сказать, запишутся ли данные или нет, даже время точно определить нельзя.

                                                                    Если не страшно потерять часть данных, то решения типа MongoDB идеально.
                                                                    • +3
                                                                      Ещё раз повторю: монгу можно использовать с ипользованием транзакций (1, 2), журналирования (1), можно определить записались ли данные на диск (1, 2), записать их принудительно (1) и много другое. В будущем, уверен, всё это доведут до ума и всё это будет красиво.
                                                                      • +1
                                                                        Хех, у меня как раз все ваши ссылки visited. А почему? Потому, что транзакции работают только в пределах одного документа, а междокументные приходится делать своими руками (1, 2), журналирование вызывает segfault, когда кончается место на диске, а при крэше процесса БД чинится дольше, чем банальный MyISAM у MySQL (10 минут на гигабайтную БД). И многое другое.

                                                                        В общем, конкретно mongodb до ума не довели пока ещё :)
                                                                  • 0
                                                                    да тот же оракл — хранит данные в дереве — а SQL это только оболочка для программистов — и обработка транзакций в SQL ориентированных БД — к SQLю не имеет никакого отношения и ещё раз напишу есть СУБД поддерживающие не реляционные модели данных с транзакциями журналированием зеркалированием теневым копированием и прочими важными нужными и полезными штуками есть знаю и работаю с СУБД Cache — но уверен одна не одна такая

                                                                    поймите SQL — не имеет никакого отношения к транзакциям — вообще никакого!
                                                              • 0
                                                                Сейчас ни Mongo, ни CouchDB могут гарантировать лишь атомарность единичной операции.

                                                                Если же, например, у вас онлайн игра, где предмет передается от 1 персонажа другому, то ни одно NoSQL решение не может гарантировать что у вас исключена ситуация, когда предмет отобран от персонажа А, но не пришел к персонажу Б.

                                                                Не знаю про Couch, но Mongo такое гарантированно умеет делать. Просто выглядеть будет несколько непривычно.
                                                                • 0
                                                                  Ага, двухфазные коммиты — костыль который не везде-то и применишь. Вместо BeginTransaction...Actions...CommitTransaction десятки, если не сотни/тысячи строк кода.
                                                                  • +1
                                                                    Из моей практики следует, что возможность атомарной операции над набором документов нужна куда как реже, чем возможность атомарного доступа к конкретному документу. Причём, даже при сборе статистики.
                                                                    • +2
                                                                      Нужно редко. Но очень сильно. :)
                                                                      • 0
                                                                        В знак согласия — Вам +1.
                                                                • 0
                                                                  Cache — древовидная СУБД — при использовании прямого доступа обеспечивает транзакционную целостность (в ней есть поддержка реляционной и объектной модели — но это только для тех кто не представляет noSQL БД)
                                                                  • 0
                                                                    Может разработчики монго специально не делают транзакции, т.к. хоть и удобный инструмент, но медленный.
                                                                    > ни одно NoSQL решение не может гарантировать что у вас исключена ситуация, когда предмет отобран от персонажа А, но не пришел к персонажу Б.
                                                                    В mongo это можно выполнить двухфазными комитами. Это конечно более сложный механизм но он не «тормозит» базу — все комиты, с одними данными, выполняются параллельно.

                                                                    Но если транзакции нужны позарез, то ничего не мешает заюзать тот же mysql для конкретной задачи.
                                                                    Очень много крупных проектов используют не одну БД/инструмент, хабр например использует sphinx search (не БД но там тоже данные), кто-то использует дополнительно memcache и т.п. Т.е. используется набор инструментов под задачи.

                                                                    PS: Кстати вот ответ по транзакциям в FAQ:
                                                                    > MongoDB does not have support for traditional locking or complex transactions with rollback. MongoDB aims to be lightweight, fast, and predictable in its performance.
                                                                    • 0
                                                                      «что у вас исключена ситуация,» — такая ситуация будет происходить в 0.000001% случаев. Для этого случая можно просто логировать все операции и восстановить ручками. Зато у вас приложение упростится в разы.

                                                                      «собенно оперирующих деньгами» — у вас данные с гораздо большей вероятностью испортятся из-за багов. Автор все правильно пишет, мы все слишком привыкли верить во все эти маркетинговые штуки типа ACID, которые если копнуть глубже не очень-то и оправданы.
                                                                    • 0
                                                                      А как же целостность данных? В этих «маленьких и быстрых» нереляционных БД, в той же упомянтой Mongo, нет (пока) ни транзакций, ни даже блокировки на уровне документа.
                                                                      • 0
                                                                        MongoDB supports atomic operations on single documents.

                                                                        www.mongodb.org/display/DOCS/Atomic+Operations
                                                                        • 0
                                                                          Даже на уровне нескольких документов поддерживает (см. комментарий выше). Но от этого ни холодно, ни жарко. Вместо элегантного SQL, поддерживающего абсолютно любые транзакции, вы получаете транзакционность для пары/тройки сценариев.
                                                                          • 0
                                                                            Как мне заблокировать от изменений все документы, участвующие в расчётах во время транзакции?
                                                                            • +2
                                                                              findAndModify + ещё одно поле документа.
                                                                              • 0
                                                                                То есть, сначала найти все используемые в транзакции документы. При этом установить им флаг, что они используются. После чего, произвести расчёты. Если во время расчётов появились ещё документы, им тоже установить этот флаг. После чего, произвести изменения и снять эти флаги. При этом, вся остальная логика должна знать и помнить, что у документа есть такой флаг, который надо учитывать. Таким образом, вроде как можно защититься от аномалий. Я правильно понял логику? Это действительно удобно, надёжно и не создаёт проблем?
                                                                                • 0
                                                                                  Приведите пример, когда такое нужно. Тем более, что, обычно, транзакции в sql вообще не позволяют обрабатывать документы, появившиеся в базе после начала этой самой транзакции.
                                                                                  • 0
                                                                                    «Появились» — я имел в виду, что к примеру, во время вычислений появилась необходимость обработать документы, о которых раньше не было известно.

                                                                                    Пример: у пользователя есть право на определённое количество голосов. При обработке запроса-голоса, производится проверка его оставшегося количества голосов и голосовал ли он за этот документ уже раньше. Если обе проверки проходят, происходят некоторые вычисления, изменения у пользователя и у документа, создание новых документов (в очереди уведомлений например), и т.д. Если некто посылает пачку одинаковых параллельных запросов, есть вероятность, что сначала будет несколько успешных проверок, а потом несколько изменений, что приведёт к недопустимым данным. Cпособ с findAndModify, по идее, должен решить такую проблему?
                                                                                    • +1
                                                                                      Можно для пользователя userId хранить множество идентификаторов статей, за которые он проголосовал.
                                                                                      Дальше (в терминах MongoDB) делаем $push новой статьи в это множество для пользователя userId, у которого такой статьи ещё нет и общее количество статей не превосходит максимальное количество голосов от пользователя.
                                                                                      В случае невыполнения условий от Монго приходит null в качестве ответа.
                                                                                      Итого: один атомарный запрос.
                                                                                      • 0
                                                                                        Это всё в findAndModify по текущему юзеру, насколько я понял, хорошо. А если при этом надо проверить дату документа, за который он голосует?
                                                                                        • 0
                                                                                          Так хранить можно не сами статьи, а ссылки на них (в терминах MongoDB — ObjectId).
                                                                                          • 0
                                                                                            В смысле? Я не понял, причём тут ссылки (кстати, ссылки вроде рекомендуют делать DBRef-ом). Проблема в том, что бывают случаи, когда надо проверить условия, связанные с разными документами. Например, проверить состояние двух счетов, если один из них не меньше суммы, а второй не больше какого-то предела, то перечислить сумму. Или, например, при вступлении пользователя в группу, проверить максимальное число членов группы, флаг закрытия, а у пользователя — права на вступление в группы и ограничение на количество групп. Этого часто невозможно сделать атомарным запросом, даже если перелопачивать структуру данных на каждое такое нововведение.
                                                                                            • +1
                                                                                              Из моего опыта — такое часто возникает только тогда, когда структура придумывается в реляционных терминах. В противном случае сценарии, которые нельзя свести к атомарным операциям с документами, относительно редки.
                                                                          • 0
                                                                            Cache — целостность транзакции журналирование теневое копирование зеркалирование — всё есть — в ней есть даже SQL с объектами — но это только для тех кто не понимает не умеет не хочет или боится работать напрямую с деревьями (глобалами)
                                                                          • +7
                                                                            Не согласен с автором.

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

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

                                                                            Сценарии использования этому ничуть не противоречат, это просто верхний этаж системы.
                                                                            • 0
                                                                              Вот только данные и система их хранения и доступа к ним — это разные вещи. И удобным представление и изменение данных должно быть для пользователя, причём именно в его сценариях использования, а не для системы хранения.
                                                                            • 0
                                                                              Скажите, а что подразумевается под термином «сценарии использования»?
                                                                            • +1
                                                                              бред какой-то. Что важнее, файлы видео твоих днейрождений за последние 15 лет или плеер который их играет?
                                                                              • +2
                                                                                А что важнее, содержимое видео или формат/контейнер, в котором оно хранится? База данных, это ведь не данные, это именно контейнер.
                                                                                • 0
                                                                                  ага только это не только контейнер но ещё и связи между контейнерами — и недооценивать (как впрочем и переоценивать) важность этих связей не есть гуд — БД это транспортная система для данных и от её архитектуры зависит будут ли пробки при извлечении этих данных или будет хайвей без ограничения по скорости

                                                                                  баланс между содержимым и формой всегда надо поддерживать — а класть яйца в одну корзину и явно ставить во главу угла одно или другое — глупо
                                                                                  • 0
                                                                                    Так может проектировать приложение так, чтобы оно не зависело от транспортной системы? Будут пробки в текущей — поменяем на хайвэй. Почему нам должно быть важно привезут заказ из магазина по хайвэю или по просёлку, если его привезут вовремя?
                                                                                    • 0
                                                                                      проектировать приложение не зависящее от транспортной системы — это то же самое что проектировать интернет приложения не обращая внимания на протокол http

                                                                                      спроектируйте город не зависящий от транспортной системы — я в нём жить не буду — гораздо разумнее проектировать город и учитывать в том числе транспортную подсистему — не ставить её во главу угла не забывать о ней а учитывать и работать над ней (для села попроще — для мегаполиса посложнее)

                                                                                      нет независимости — в том числе и в проектировании — есть только баланс — и к нему надо стремиться — его надо чувствовать — а тупое бездумное деление на красных и белых, sql/nosql, БД/не БД — это детский сад
                                                                                      • +1
                                                                                        Сейчас широко распространена практика независимости приложения от HTTP, запрос ы и ответы инкапсулируется в объекты или другие структуры данных. Это, в частности, позволяет тестировать функциональность приложения не пользуясь веб-сервером и клиентами.

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

                                                                                          а автор статьи всё же склонен к бездумному — «ты не снами — значит ты против нас»
                                                                              • +4
                                                                                После прочтения первой части статьи думал, что автор ругает реляционные БД и предлагает всем вернуться во времена хранения данных в файликах. Эта мысль конечно же бредова. Однако во второй части автор наконец раскрыл истинный смысл статьи — ценность проекта не в том, какую систему хранения он использует, а в реальной полезности, сценариях использования. Ведь его фирма загнулась не потому, что использовала хранения в файликах, а потому что слишком много думала над системами хранения, вместо того, чтобы решать бизнес-задачи и зарабатывать баксы.

                                                                                Лично я воспринял это, как урок стартаперам, которые еще на этапе идеи начинают говорить, «а вот тут мы заюзаем MongoDB и у нас будет web scale, а там мы заюзаем Redis». Для технологических стартапов это актуально, но для остальных — нет. У основателей стартапов голова часто забита тем, какие фреймворки и системы хранения заюзать в новом проекте, вместо того, чтобы думать о пользе для конечного юзера, маркетинге и прочих бизнес-задачах.
                                                                                • 0
                                                                                  habrahabr.ru/post/204392/
                                                                                  для тех, кто не в курсе, причём MongoDB к web scale — вот перевод «MongoDB is web scale»
                                                                                • 0
                                                                                  Тут автор излагает эту идею на чуть более конкретных вещах: http://www.youtube.com/watch?v=WpkDN78P884.
                                                                                  • 0
                                                                                    Вот этот вот пассаж: «I watched as SQL slipped through every crack and crevice in the system. I ran screaming from systems in which SQL had leaked into the UI. I railed endlessly against the practice of moving all business rules into stored procedures. I quailed and quaked and ranted and raved as I read through entire mail-merge programs written in SQL.» (извините, что не перевод) — это аккурат то, что я чувствую и наблюдаю сейчас. Гигантская система, over 90% бизнес-логики которой находится в SQL. Поддержка этого похожа на непрекращающийся кошмар.

                                                                                    BTW, о переводе: mail-merge — это не почтовая рассылка, это подготовка данных для нее, причем сама рассылка может быть бумажной.
                                                                                    • 0
                                                                                      > Поддержка этого похожа на непрекращающийся кошмар.

                                                                                      А не расскажите в чем кошмар? Я вот подумываю один проект перевести на хранимки, что бы бегало быстрее. Да, я зык странноват и нет привычной IDE но язык хранимок достаточно мощный. Так в чем же проблемы? Может там у вас просто качество кода плохое?
                                                                                      • +1
                                                                                        «А не расскажите в чем кошмар?»
                                                                                        Нет контроля зависимостей, нет адекватного рефакторинга, нет build-time verification, очень сложно тестировать.

                                                                                        «Так в чем же проблемы?»
                                                                                        Перечислено выше. Добавьте к этому тот знаменательный факт, что управлять версиями кода на SQL-сервере тоже сложнее, и вы получаете замечательный локальный ад.

                                                                                        «Может там у вас просто качество кода плохое? „
                                                                                        Да, там плохое качество кода. Но чтобы оно было хорошее, нужно, чтобы было все вышеперечисленное, потому что залог качества кода — рефакторинг. А его нельзя адекватно делать без поддержки на уровне инструментов и тестирования. Замкнутый круг.
                                                                                    • 0
                                                                                      Когда лучше определиться с моделью данных? Когда вы знаете, какие есть объекты данных, как они связаны и как они используются. Когда вы это узнаете? Когда все сценарии использования и бизнес правила записаны и проверенны.

                                                                                      Макконнелл бы не согласился. Написание кода не имеет никакого отношения к проектированию. А проектирование предшествует кодированию.
                                                                                      • 0
                                                                                        В цитате нет ничего про код.
                                                                                        • 0
                                                                                          Существуют другие точки зрения, например в XP методиках проектирование скорее пост-фактум в виде рефакторинга, чем перед кодированием.
                                                                                        • 0
                                                                                          Почему-то не забывается такой аспект как сложность рефакторинга баз данных. Изменить алгоритм обработки ничего не стоит, изменение модели данных тянет за собой груз всех накопленных до этого данных.

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

                                                                                          Модель данных — это как public API. После того, как она была запущена в жизнь любое изменение обходится очень и очень дорого.

                                                                                          • 0
                                                                                            Рефакторить базу данных так же легко, как и код, если не легче. Но вы правы, если БД работает, то рефакторить сложнее — не откуда брать данные, в случае, если они не фиксировались. Но а откуда брать данные, если рефакторить код с т.з. таких же измененний? Допустим, не держим реляционную БД. То же самое. Чудес не происходит, информацию родить нельзя.

                                                                                            Реляционная БД тем и хороша, что в ней более наглядно видны такие проблемы. И легко моделируется предметная область. В определенных пределах.

                                                                                            Проблема автора, по моему мнению, что он БД рассматривает, как нечто связанное с реализацией, нечто второстепенное. Так никто ж и не заставляет писать кривую схему непонятно чего. Если в БД моделировать предметную область (т.е. всем понятно — таблицы — сущности или связи и т.д.), то никаких проблем с юз-кейсами, от которых отталкиваться проектирование и разработка должны — нет.
                                                                                            • 0
                                                                                              Зачем в БД моделировать предметную область? Может лучше смоделировать предметную область, а потом отобразить её на БД (или любое другое хранилище)?
                                                                                              • +1
                                                                                                БД для этого хорошо подходит. А чем лучше смоделировать ее в коде, а из БД делать хранилище?

                                                                                                В БД моделировать — дело минут. Создать таблицы, связи и ограничения. Декларативный способ.

                                                                                                Реляционная БД позволяет как бы создать зависимости между данными другим (не ООП) способом. Но этот способ жестче — дает возможность применять реляционную алгебру. При этом, данные можно представить, как некий н-мерный куб. Это дает возможность обобщать. Видеть упущенные требования.

                                                                                                Ограниченния реляционной БД — это как статическая типизация. Если в коде вы для переменной ставите целочисленный тип, зная, что это будет счетчик, то не жалуетесь, что тип ограничен и не позволит вам в будущем там хранить число с плавающей точкой. Схема БД — это такая типизация, где на уровне схемы будет проверяться взаимосвязь с данными. И на уровне схемы выражается практически вся предметная область, еще без строчки кода.

                                                                                                Хотя, бывает, конечно, не всё можно выразить, но многое. Зачем же упускать такую возможность. А гибкость кода — это возможность багов.
                                                                                                • 0
                                                                                                  Возможность формально все описать — это палка о двух концах. Так же как языки со статической типизацией и динмической: одни дают строгость, другие гибкость. Как видите никто еще не победил в этой вселенской битве строгость vs гибкость (waterwall vs agile, static typing vs dynamic typing, etc). Победителя и не может быть. Все зависит от требоний более выского порядка вроде бизнес-модели.
                                                                                                  • +1
                                                                                                    В РСУБД плохо моделируются иерархические и/или рекуррентные системы, системы с произвольными атрибутами и т. п., а такие задачи сплошь и рядом. Да банальное отношение многие-ко-многим уже не тривиально реализуется, требует введения дополнительной таблицы, которая на предметную область никак не отображается.

                                                                                                    Выразить-то можно многое, но далеко не всегда это будет естественным и/или эффективным варажением. Я согласен с автором, что роль SQL РСУБД переоценена, они выступают в роли «серебрянной пули», разработчики зачастую выбирают не как хранить данные, а в какой SQL РСУБД их хранить, даже не задумываясь о целесообразности использования именно SQL РСУБД. Доходит до того, что настройки приложения хранят в базе данных.
                                                                                                    • 0
                                                                                                      «В РСУБД плохо моделируются иерархические и/или рекуррентные системы»

                                                                                                      Насколько я понимаю, моделируются просто, работают СУБД с такими вещами неэффективно. SQL плохо подходит.

                                                                                                      Многие ко многим реализуются отдельной таблицей. Это не такой удар по предметной области. Просто помнить, что таблица не обязательно бывает сущностью, а может быть и связью. Иногда, эта связь по мере моделирования становится сущностью. Просто добавляются еще атрибуты. Поэтому суть размыта, где таблица связи и почему она не сущность.

                                                                                                      Системы с произвольными атрибутами реляционно не реализуются. Но не согласен, что такие задачи сплошь и рядом. Представьте себе систему, написанную на объектно-ориентированном языке без БД. Аналог этой задачи — вы не знаете во время компиляции, сколько и какого типа полей у объекта будет. И вы будете формировать тип в рантайме. Еще тот фокус. Иногда надо. Но или на динамических языках пишут или просто пишут классы, которые будут потом атрибутами другого класса в списке, а им добавляют тип, который что-то вроде перечисления. Т.е. фактически не пользуются уже типизацей языка, а выворачивают его так, чтобы создать собственную динамическую типизацию.
                                                                                                      Точно таким же хаком и в реляционной БД поступают, если такое нужно.
                                                                                                      • 0
                                                                                                        ох…

                                                                                                        Системы произвольными атрибутами реляционно реализуются. Легко и непринуждённо. Равно как и обработка иерархических данных. РСУБД потому и завоевали мир 30 лет назад — они были тупо удобней в большинстве задач чем иерархические БД коими по сути являются все эти NoSQL.
                                                                                                        • 0
                                                                                                          Вы не поняли. Я подразумевал, что честно реляционным способом не реализуются.
                                                                                                          А завести табличку с называнием Attribute и с колонками что-то вроде Name, Value, Type можно.
                                                                                                          Или делают денормализацию — лишние колонки, которые пользуют, как захочется потом и сколько надо. Или делают табличку, в которой общий тип текстовый или какой-то, которые приводят потом к чему хотят.

                                                                                                          По сути, это подобный хак, как и в ООП (шарп, джава) со статической типизацей был бы. Просто в языках таких всё на хаках, кругом императивщина. Поэтому там не так заметно, когда язык выворачивают. Создают новое свое измерение для типизации.
                                                                                                          • 0
                                                                                                            Дада, реляционщики поступают бесчестно. Читят.

                                                                                                            Повторюсь

                                                                                                            РСУБД потому и завоевали мир 30 лет назад — они были тупо удобней в большинстве задач чем иерархические БД коими по сути являются все эти NoSQL.
                                                                                                            • 0
                                                                                                              да я ж только за. Наоборот защищаю реляционные БД
                                                                                                • 0
                                                                                                  «Рефакторить базу данных так же легко, как и код, если не легче.»
                                                                                                  Ась? Предположим, у нас есть _самая простая задача_ — нам надо переименовать объект (скажем, таблицу). Предположим также, что у нас идеальный случай, и БД не используется для интеграции (т.е., она не является публичным контрактом, потому что в этом случае мы обречены). Внимание, вопрос: какой инструмент позволит мне найти _все_ упоминания этого объекта в (а) коде самой БД (б) коде соседних БД (ц) прикладном коде, автоматически их изменить, а потом проверить на уровне компиляции кода, что ни одна ссылка не потерялась?

                                                                                                  Альтернативный ход: есть два представления, одно использует другое, я подвинул часть логики из одного в другое (типичный рефакторинг). Какой инструмент позволит мне покрыть это все изолированными тестами, чтобы быть уверенным, что мои изменения ничего не повредили?
                                                                                                  • 0
                                                                                                    таблица это не объект. Даже не рядом. Задача поставлена неверно. Хотя анализ всех упоминаний определённой таблицы во всех процедурах и всех определениях делается одним запросом.

                                                                                                    тесты кода к базе данных неприменимы. Там же описание связей и сущностей а не императивный язык типа с++. Если в описании таблицы стоит связь с родительской таблицей то никогда и ни при каких условиях неверное значение туда не попадёт. Это гарантируют SQL серверы и сотни человеко-лет их разработки. А вот тесты программы которая обращается к данным пишут. И тут эти тесты ничем не отличаются от любых других случаев.
                                                                                                    • 0
                                                                                                      «таблица это не объект»
                                                                                                      Не объект БД? Интересно, почему.

                                                                                                      «Задача поставлена неверно»
                                                                                                      Что в этом неверного? Это типовая задача при рефакторинге БД.

                                                                                                      «Хотя анализ всех упоминаний определённой таблицы во всех процедурах и всех определениях делается одним запросом.»
                                                                                                      Замена тоже?

                                                                                                      «Там же описание связей и сущностей, а не императивный язык типа с++»
                                                                                                      И вы мне хотите сказать, что никогда не видели БД, в которой были бы не только сущности и связи, но еще и код: представления, хранимые процедуры, функции, триггеры?

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

                                                                                                      «Если в описании таблицы стоит связь с родительской таблицей то никогда и ни при каких условиях неверное значение туда не попадёт. Это гарантируют SQL серверы и сотни человеко-лет их разработки. „
                                                                                                      Да-да. Ссылочная целостность, я слышал. Между двумя БД, говорите? Не работает.

                                                                                                      И это все только при условии, что у вас изначально правильно построена БД. А вот если вы при проектировании какое-то ограничение пропустили, а теперь пытаетесь его наложить — а это рефакторинг — то ваша жизнь будет намного сложнее.
                                                                                                    • 0
                                                                                                      Вопрос только в инструменте?

                                                                                                      Сам подход — моделирование в БД ничем не хуже моделирования в шарпе. Даже лучше иногда. Чем код создания таблиц и связей так плох по сравнению с другим языком? Если вопрос только в инструменте — то это мелко. Я не базовик, там есть разные не известные мне инструменты.
                                                                                                      ERwin например. Базовики пользуются и хвалят. Не знаю его возможностей.

                                                                                                      VS-2010 имеет тип проекта для работы с MS-SQLSERVER. Прямо переименовываниями не вижу, чтобы занималась, но она имеет возможность делать «билд», т.е. проверить всё. А значит покажет, что что-то потерялось в случае переименования.

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

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

                                                                                                      Инструменты — не такая уж проблема. Завязываться на них, выбирая технологию, не стоит. На прошлой работе, например, базовику не нравился синтаксис TRANSACT-SQL. Он прикрутил препроцессор С. Свободный. И там понаписывал макросы подмены, в результате писал на более удобном для себя синтаксисе. Циклы и ветвления похожи на С были.

                                                                                                      Потом, при отсутствии инструмента можно вполне без проблем построить даже самому разворачивание базы из скриптов. Билд-сервер настроить. И там уже как хотите — переименовывайте. Сделаете анализатор.
                                                                                                      Конечно, сделать полный парсер SQL сложно. Но анализ связей вполне можно. И поиск по вхождению слова без проблем. А на запросы написать тесты тоже можно.
                                                                                                      • 0
                                                                                                        «Вопрос только в инструменте?»
                                                                                                        Вопрос в философии. Когда мы меняем код, мы меняем алгоритм. Когда мы меняем базу, мы меняем уже существующие данные.

                                                                                                        «Чем код создания таблиц и связей так плох по сравнению с другим языком?»
                                                                                                        Смотря для чего.

                                                                                                        «VS-2010 имеет тип проекта для работы с MS-SQLSERVER. Прямо переименовываниями не вижу, чтобы занималась, но она имеет возможность делать «билд», т.е. проверить всё. А значит покажет, что что-то потерялось в случае переименования.»
                                                                                                        Вы с ним работали? Я работал. Никакого «билда» в смысле компиляции там нет, тамошний «билд» — это расчет скриптов изменений.

                                                                                                        «Инструмент написать можно быстро.»
                                                                                                        Почему его до сих пор нет?

                                                                                                        «Имена таблиц, как уже сказано, не имеет смысла покрывать тестами. „
                                                                                                        То есть у вас никогда не было ошибок из-за того, что таблицу переименовали, а использующий ее код (не важно, в БД или в приложении) — не поправили? У меня были.

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

                                                                                                        «Завязываться на них, выбирая технологию, не стоит.»
                                                                                                        Не стоит? Ну если для вас двух-трехкратная разница в производительности работы сотрудника не стоит выбора технологии, то я даже не знаю, что его стоит.

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

                                                                                                        А вообще, ваш пост — хорошая демонстрация того, почему базу рефакторить не так же просто, как и код. Потому что «напишите, напишите, напишите, настройте». А для кода уже все есть. Поэтому — рефакторинг и разработка на уровне БД _сложнее_. Не невозможна, нет. Просто сложнее и дороже.

                                                                                                        Я вижу это каждый день, имея возможность сравнить стоимость типичных рефакторингов в .net-команде и sql-команде. Во второй их практически нет.
                                                                                                        • 0
                                                                                                          «Вопрос в философии. Когда мы меняем код, мы меняем алгоритм. Когда мы меняем базу, мы меняем уже существующие данные.»

                                                                                                          Конечно. Если бы у вас не было БД, а вы хранили данные в файлах, например. И писали только на шарпе (или джаве и т.д.). Такой идеал, как автор предлагает. И запустили систему в продакт. А потом нужен рефакторинг кода. Упс — та же проблема. Если информация утеряна, ее из космоса получить невозможно.
                                                                                                          Даже если у вас проект с БД и вы выкатили в продакт, а потом рефакторите код, и он затрагивает объекты, которые уже хранятся в БД — та же проблема. Потеря данных.

                                                                                                          Если же вы не выкатывали ничего в продакт, а находитесь как положено на этапе разработки системы, то рефакторить можно и то и другое.
                                                                                                          Алгоритмы работают с данными. Если у вас такой случай, что не надо трогать данные — то отлично, рефакторите без проблем. А если надо, то СУБД в этом не виновна. Эти проблемы будут всё равно.

                                                                                                          «Вы с ним работали? Я работал. Никакого «билда» в смысле компиляции там нет, тамошний «билд» — это расчет скриптов изменений.»
                                                                                                          немного. Я «олдскульный». Всё скриптами пользуюсь ))
                                                                                                          Но «билд» — замечательная вещь. Конечно, там нет компиляции, потому что и не может для SQL-SERVER компиляции. Для скриптового языка. Но расчет скриптов изменений — это то, что нужно. Он позволяет указать любые ошибки. Вот как раз проверить все запросы на предмет соотвествия именам таблиц и колонкам.

                                                                                                          «Интересно, как ваш «движок» изолирует тестируемый код от его зависимостей»
                                                                                                          Тестовый движок, это отдельная база данных. Состоит из нескольких несложных хранимок. Сам тест — хранимая процедура. Этому движку указывается, к какой базе данных нужно приконектиться. И она вытягивает в свою базу требуемые для теста таблицы (пустые, только структура), хранимки, функции и т.д.
                                                                                                          Тест начинается с указания какие таблицы нужны. Далее заполнение тестовыми данными. И прогон тестов.
                                                                                                          Всё просто. На самом деле кода не много. А развязка от тестируемой базы неплохая. Тесты это хорошо выручают.
                                                                                                          Но тесты эти тестируют только код. Например, зависимости между таблицами не вытягиваются. Декларативную часть бессмысленно тестировать.

                                                                                                          «Не стоит? Ну если для вас двух-трехкратная разница в производительности работы сотрудника не стоит выбора технологии, то я даже не знаю, что его стоит»

                                                                                                          Конечно, важна производительность сотрудника. Я только говорю о том, что часто переоценивают проблемы. Эти проблемы решаются разово и тратится на них время не такое большое. Программисты мы или кто? У нас в конторе например, выбирали ORM и боялись, что в некоторых вариантах не генерировались классы по БД. Объяснил как, и дело пошло. Людям казалось, что это сложно. А оказывается, совсем нет.

                                                                                                          «Угу. Спасибо за предложение заниматься интеграционными тестами. Проблема в том, что это — дороже, чем изолированные.»

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

                                                                                                          «А вообще, ваш пост — хорошая демонстрация того, почему базу рефакторить не так же просто, как и код. „

                                                                                                          Тут другая тема есть. Кода на СУБД меньше. Следовательно и рефакторинг в этом плане будет проще. Если данные потеряны, то сложно будет и в слое над БД. Если нет, то рефакторинг в БД не сложный. Даже не знаю, как кратко описать. О рефакторинге кода писал Фаулер. Там всё строится почти на выносе метода или выносе класса. В БД — вынос сущности (не только это, конечно, но чаще всего). Была колонка, стала отдельной сущностью. Всё это — декларативное описание. Как по мне, и работы меньше.

                                                                                                          “Я вижу это каждый день, имея возможность сравнить стоимость типичных рефакторингов в .net-команде и sql-команде. Во второй их практически нет.»

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

                                                                                                          • 0
                                                                                                            «Если же вы не выкатывали ничего в продакт, а находитесь как положено на этапе разработки системы, то рефакторить можно и то и другое. „
                                                                                                            К сожалению, очень многие сегодняшние системы постоянно находятся в продуктиве. Поэтому никакого “как положено на этапе разработки» не будет.

                                                                                                            «А если надо, то СУБД в этом не виновна. Эти проблемы будут всё равно.»
                                                                                                            Я всего лишь говорю, что рефакторить БД — не важно, какую, хоть файловую — дороже, чем рефакторить код. Вот и все.

                                                                                                            «Но расчет скриптов изменений — это то, что нужно. Он позволяет указать любые ошибки.»
                                                                                                            _указать_ — возможно. Но сам он их не находит.

                                                                                                            «Вот как раз проверить все запросы на предмет соотвествия именам таблиц и колонкам.»
                                                                                                            Вот только он этого не делает. Особенно для сторонних БД.

                                                                                                            «Тестовый движок, это отдельная база данных. Состоит из нескольких несложных хранимок. Сам тест — хранимая процедура. Этому движку указывается, к какой базе данных нужно приконектиться. И она вытягивает в свою базу требуемые для теста таблицы (пустые, только структура), хранимки, функции и т.д.
                                                                                                            Тест начинается с указания какие таблицы нужны. Далее заполнение тестовыми данными. И прогон тестов.
                                                                                                            Всё просто.»
                                                                                                            Занятное решение. Но очень медленное, к сожалению.

                                                                                                            «Декларативную часть бессмысленно тестировать.»
                                                                                                            Расскажите это разработчикам декларативных DSL. Тестировать осмысленно все.

                                                                                                            «Эти проблемы решаются разово и тратится на них время не такое большое. Программисты мы или кто?»
                                                                                                            Вы оптимист. Мы вот (простую) проблему версионирования БД решаем который месяц.

                                                                                                            «Кода на СУБД меньше.»
                                                                                                            Это если вам повезло.

                                                                                                            «Если нет, то рефакторинг в БД не сложный. Даже не знаю, как кратко описать.»
                                                                                                            А зачем описывать, по этому поводу отдельная книжка есть. И там очень неплохо видно, насколько это сложнее рефакторинга кода.

                                                                                                            «Была колонка, стала отдельной сущностью. Всё это — декларативное описание.»
                                                                                                            Ага. Очень просто. Теперь пошли и проапдейтили (вручную, потому что автоматических инструментов нет) все, что эту колонку использовало. Потом прогнали интеграционные (и выше) тесты, и через неделю нашли код, который не заметили на первой фазе.

                                                                                                            Сравнить с Ctrl-R, R в решарпере — и хочется плакать.

                                                                                                            «я и sql-команд не видел.»
                                                                                                            Оно и заметно, простите за прямоту.
                                                                                                            • 0
                                                                                                              «Занятное решение. Но очень медленное, к сожалению.»

                                                                                                              Да, есть такое. Но это было первое решение. Я немного переделал движок. Дело в том, что если один и тот же объект нужен не одному тесту, то не обязательно его убивать и снова вытягивать. Таблицы только чистить.

                                                                                                              Да самому стыдно за движок — велосипеды сочиняю :)) Но какого-то готового решения не нашел. Может плохо искал. Майкрософтовский вместе со студией стоит дорого. Не захотели на каждого разработчика покупать такую версию студии.

                                                                                                              Здесь описал движок, как пример, что при отсутствии инструмента — не так сложно его сделать.
                                                                                                  • 0
                                                                                                    Модель данных и схема БД вещи вообще говоря не связанные. Эта связь прячется или в модели (ActiveRecord) или в отдельной системе (DataMapper) и легко модифицируется как раз алгоритмами.