Здравствуйте, alex_public, Вы писали:
IB>>Ааааа! Я хочу в этот мир!
_>Приглашаю) Для этого достаточно выглянуть за пределы мира внутрикорпоративного ПО. )
Можно подумать, вне корпоративного софта треботвания никогда не меняются, ога.
Вот простой кейс — кастомер вначале бьёт пяткой в грудь, утверждая, что десктопное приложение должно запускаться ровно в одном экземпляре и ровно в одном окне. Это приложение использует унутре базу, в принципе, не важно даже какую, где хранятся все данные. Через год кастомеру приходит в голову интересная мысль, что окон может быть больше одного. Здесь уже появляется проблема — UI в разных окнах отражает вобщем те же данные, что и в других. Отсюда ясно, что изменения одного окна должны отображаться во всех. И тут появляются такие кейсы — в одном окне юзер открыл объет, а в другом его же удаляет. Внезапно, это требует принципиально иную архитектуру.
Далее, тот же кастомер требует, что бы можно было открывать более одного инстанца. Опаньки — для одного инстанца хватает двух-уровневой архитектуры. С несколькими инстанцами это больше не работает, а состояние на ровном месте стало разделяемым.
Отсюда хочется узнать, какими скилами должен обладать проектировщик, что бы заранее предсказать, что требования изменятся с точностью до наоборот. То есть, проектировщику ни много ни мало, надо обладать машиной времени или же скомпенсировать эту недостачу какими то скилами. Вот и вопрос — что за мифические скилы такие у проектировщика в твоей области.
Здравствуйте, Sinclair, Вы писали:
S>А на машинке за $1000 вы ничего интересного захостить не сможете — она умрёт быстрее, чем вы задеплоите первую версию.
Антон, ты не поверишь сколько сейчас стоит та железка, на которой работает этот сайт — в районе 1500 баксов.
_>Приглашаю) Для этого достаточно выглянуть за пределы мира внутрикорпоративного ПО. )
Друг мой, последние 8 лет я делаю публичные сервисы и коробки. Хорошо делаю, качественно, миллионами штук...
Раскрою страшную тайну — в корпоративном ПО порядка и предсказуемости существенно больше.
Здравствуйте, alex_public, Вы писали:
_> Redis — это не кэш, т.к. хранит данные на диске (хотя это и можно отключать). Пример кэша — это memcached, который действительно живёт только в оперативной памяти.
Кэш — это не про "где хранится". Кэш — это про "можно быстро достать по ключу".
И таки да — во всех вменяемых проектах NoSQL используется исключительно в качестве рапределенного кэша, под которым лежит нормальное SQL хранилище.
Здравствуйте, alex_public, Вы писали:
_>С блобами невозможно производить никакие операции: нет ни индексов, ни поиска, ни модификации. Абсолютно не интересная вещь и даже близко не являющаяся аналогией документа в nosql БД.
Модификация конечно же есть.
Индексы и поиск реализуются поверх key:value на блобах точно так же, как и в вашей любимой nosql БД. Единственный недостаток — это необходимость поднимать блоб в апп-сервер для десериализации; это единственная реально оптимизированная по сравнению с олдскульным SQL операция. Ну и таки да — постгрес умеет JSON из коробки; SQL Server из коробки умеет XML, остальных можно научить и тому и другому при помощи "нестандартных расширений".
_>Аргументированно. )))
А какие вам нужны аргументы? В SQL вы можете хранить вектор значений в блобе (что является прекрасным решением для слабоструктуированных данных, к которым вам не нужен высокогранулярный доступ), а можете — в честной таблице. В обоих случаях вы не жертвуете ACID, и решение можно принимать исходя из нефункциональных требований вроде производительности и стоимости будущих модификаций. А в NoSQL у вас схема данных непосредственно влияет на функциональность.
Это означает, что при изменении требований (типа "а давайте всё же сделаем так, чтобы была хоть какая-то консистентность"), вам придётся изменять схему, а в бессхемной базе это, мягко говоря, пипец. Ваши представления о том, что хороший проектировщик может зафиксировать требования на годы вперёд — утопичны.
_>Само наличие связей между документами ничему не противоречит. Речь была об отсутствие строгих инвариантов между документами.
"отсутствие строгих инвариантов" — это эвфемизм для уровня консистентности "нам пофиг".
_>Ммм, а я где-то писал, что надо вообще всё писать на nosql БД? ) Я вообще то вполне себе использую sql базы. И на серверах оно у нас живёт для форумов (хотя сейчас я бы уже взял nodebb и nosql БД) и систем регистрации/активации/оплаты. И в приложение sqlite используется (хотя посматриваем на unQLite, кстати, это nosql решение поддерживающее ACID транзакции). Для всего нужны свои инструменты. Просто sql решения в прошлом занимали настолько доминирующее положение исключительно по историческим причинам, а сейчас их хорошо двигают в положенное им реально место. Но естественно никто не собирается отказываться от них вообще. Я вас умоляю. Основным мотиватором внедрения NoSQL до сих пор является некомпетентность. "О, раньше нам нужен был веб-девелопер, джава-девелопер, и сиквел девелопер. А теперь мы оставим одного веб-девелопера, потому что весь стек на джаваскрипте". Единичные случаи, когда внедрение NoSQL происходит в квалифицированной команде, мало что показывают. Потому что те команды способны написать свою RDBMS и вовсе с нуля; в таких проектах ведущая роль в успехе проекта принадлежит команде, а не монге.
Для простого девелопера/стартапа/менеджера это означает, что пытаться воспроизводить опыт одноклассников — самоубийство. Там, где вы читаете "они взяли монгу, подпилили, и у них всё получилось", я читаю "они взяли мегакрутых перцев, и полгода пилили решение для трёх видов операций". Чтобы реплицировать их опыт в своём проекте, надо брать не монгу, а нанимать чуваков того же уровня. Что может обойтись значительно дороже ентерпрайз лицензии на MS SQL Server.
_>Вообще то CAS как раз обычно применяют для ускорения, т.к. при этом можно избежать блокировок. ))) Хотя там есть свои нюансы с быстродействием... Вообще это большая и популярная тема. )
Вы пытаетесь переносить подходы для межпотоковой синхронизации на ccNUMA архитектуре в мир распределённых приложений.
_>А я где-то писал, что собираюсь писать банковское ПО на монге? )))
Ну вы же мне тут втираете, что лёгким движением руки приделаете ACID к монге. А я вам пытаюсь объяснить, что этот ACID будет тормозным убогим подобием тёплого лампового ACID из мира SQL. Если вам не нужен ACID — вам повезло, можно хранить данные в чём угодно. Вам запросто может хватить вообще голой FS, безо всякой СУБД. А если таки нужен, то я бы крайне не советовал велосипедить свой. Кроме случаев, когда это и есть ваша ключевая компетентность.
_>Если реально нужна SQL БД с ACID транзакциями и т.п. то зачем трогать монгу? ))) Только вот на практике это как раз не особо часто требуется, а sql используется скорее по историческим причинам (просто ничего другого раньше не было, да и сейчас ещё не все успели изучить современные инструменты).
Ок, давайте перейдём от технических вопросов к вопросам проектирования. ACID выражает интуитивное представление о корректной работе программы. Это то, чего ожидают все клиенты, если с ними не обсуждать иного.
Как вы предлагаете проводить анализ требований к консистентности — т.е. как вы узнаете, какими инвариантами можно пожертвовать?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>Ну а что касается озвученных мною цифр, то даже если брать недешёвый HP, то какой-нибудь DL380e G8/DL180 G9 спокойно потянет приличную нагрузку. S>>А на машинке за $1000 вы ничего интересного захостить не сможете — она умрёт быстрее, чем вы задеплоите первую версию. _>Ну да, если на винде и с sql server, то может быть)))
Нет, просто вы посмотрели на цены в $1300 за сервер без дисков и обрадовались. Добавите диски в ваш DL380 — и он вам встанет в половину R920. А чтобы порвать R920 по производительности, вам придётся зарядить штуки четыре таких DL380. Это если пренебречь потерями на синхронизацию между нодами.
_>Уже же вроде обсуждалось здесь. Redis — это не кэш, т.к. хранит данные на диске (хотя это и можно отключать). Пример кэша — это memcached, который действительно живёт только в оперативной памяти.
Не важно, где кэш хранит данные. ISA тоже хранит их на диске, что не делает из него СУБД. Важна функциональность.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>>>И соответственно применение транзакций для сохранения инвариантов связанных значений. В случае же nosql БД выбор обычно побогаче. S>> S>>В случае NoSQL выбор обычно победнее.
_>Аргументированно. )))
Так же аргументированно, как и предыдущие ваши высказывания по этой теме.
P.S. ))))))))))))))))))))))))) — следуя вашему стилю ответов . Да, лол .
Здравствуйте, Ikemefula, Вы писали:
I>Можно подумать, вне корпоративного софта треботвания никогда не меняются, ога. I>Вот простой кейс — кастомер вначале бьёт пяткой в грудь, утверждая, что десктопное приложение должно запускаться ровно в одном экземпляре и ровно в одном окне. Это приложение использует унутре базу, в принципе, не важно даже какую, где хранятся все данные. Через год кастомеру приходит в голову интересная мысль, что окон может быть больше одного. Здесь уже появляется проблема — UI в разных окнах отражает вобщем те же данные, что и в других. Отсюда ясно, что изменения одного окна должны отображаться во всех. И тут появляются такие кейсы — в одном окне юзер открыл объет, а в другом его же удаляет. Внезапно, это требует принципиально иную архитектуру. I>Далее, тот же кастомер требует, что бы можно было открывать более одного инстанца. Опаньки — для одного инстанца хватает двух-уровневой архитектуры. С несколькими инстанцами это больше не работает, а состояние на ровном месте стало разделяемым.
I>Отсюда хочется узнать, какими скилами должен обладать проектировщик, что бы заранее предсказать, что требования изменятся с точностью до наоборот. То есть, проектировщику ни много ни мало, надо обладать машиной времени или же скомпенсировать эту недостачу какими то скилами. Вот и вопрос — что за мифические скилы такие у проектировщика в твоей области.
Что-то я не понял, кто это у тебя такой кастомер. Судя по тому, что он один и при этом ещё выдаёт требования, то это скорее заказчик. Т.е. скорее всего речь опять же идёт о внутрикорпоративном ПО, просто в варианте аутсорса.
Здравствуйте, IB, Вы писали:
_>>Приглашаю) Для этого достаточно выглянуть за пределы мира внутрикорпоративного ПО. ) IB>Друг мой, последние 8 лет я делаю публичные сервисы и коробки. Хорошо делаю, качественно, миллионами штук... IB>Раскрою страшную тайну — в корпоративном ПО порядка и предсказуемости существенно больше.
Здравствуйте, IB, Вы писали:
IB>Кэш — это не про "где хранится". Кэш — это про "можно быстро достать по ключу". IB>И таки да — во всех вменяемых проектах NoSQL используется исключительно в качестве рапределенного кэша, под которым лежит нормальное SQL хранилище.
Из SQL БД при определённых раскладах тоже можно очень быстро "достать по ключу" (кстати, насколько я помню как раз такой вариант работы с mysql и использовал когда-то facebook) — это теперь тоже кэш? )
Здравствуйте, alex_public, Вы писали:
_>Что-то я не понял, кто это у тебя такой кастомер. Судя по тому, что он один и при этом ещё выдаёт требования, то это скорее заказчик. Т.е. скорее всего речь опять же идёт о внутрикорпоративном ПО, просто в варианте аутсорса.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, IB, Вы писали:
IB>>Кэш — это не про "где хранится". Кэш — это про "можно быстро достать по ключу". IB>>И таки да — во всех вменяемых проектах NoSQL используется исключительно в качестве рапределенного кэша, под которым лежит нормальное SQL хранилище.
_>Из SQL БД при определённых раскладах тоже можно очень быстро "достать по ключу" (кстати, насколько я помню как раз такой вариант работы с mysql и использовал когда-то facebook)
раскладывать придётся очень определённо.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Sinclair, Вы писали:
_>>С блобами невозможно производить никакие операции: нет ни индексов, ни поиска, ни модификации. Абсолютно не интересная вещь и даже близко не являющаяся аналогией документа в nosql БД. S>Модификация конечно же есть. S>Индексы и поиск реализуются поверх key:value на блобах точно так же, как и в вашей любимой nosql БД. Единственный недостаток — это необходимость поднимать блоб в апп-сервер для десериализации; это единственная реально оптимизированная по сравнению с олдскульным SQL операция. Ну и таки да — постгрес умеет JSON из коробки; SQL Server из коробки умеет XML, остальных можно научить и тому и другому при помощи "нестандартных расширений".
Чего чего? ) Вот мы храним в блобах некие сложные объекты и хотим получить из БД все строки, в которых одно из полей данного объекта имеет определённое значение. Как будет выглядеть такой запрос в sql БД? ) Естественно не прибегая к нестандартным расширениям, типа json в PostreSQL.
_>>Аргументированно. ))) S>А какие вам нужны аргументы? В SQL вы можете хранить вектор значений в блобе (что является прекрасным решением для слабоструктуированных данных, к которым вам не нужен высокогранулярный доступ), а можете — в честной таблице. В обоих случаях вы не жертвуете ACID, и решение можно принимать исходя из нефункциональных требований вроде производительности и стоимости будущих модификаций. А в NoSQL у вас схема данных непосредственно влияет на функциональность.
Хранить вектор в блобе — это бред, который подходит только в очень редких случаях, когда с данными не надо делать никаких операций (кстати, по сути как раз случай БД ключ-значений ).
S>Это означает, что при изменении требований (типа "а давайте всё же сделаем так, чтобы была хоть какая-то консистентность"), вам придётся изменять схему, а в бессхемной базе это, мягко говоря, пипец. Ваши представления о том, что хороший проектировщик может зафиксировать требования на годы вперёд — утопичны.
ОК, давай перейдём к практике. Вот допустим возьмём этот форум (rsdn) — сколько раз в год меняется его схема БД? )
S> Я вас умоляю. Основным мотиватором внедрения NoSQL до сих пор является некомпетентность. "О, раньше нам нужен был веб-девелопер, джава-девелопер, и сиквел девелопер. А теперь мы оставим одного веб-девелопера, потому что весь стек на джаваскрипте". Единичные случаи, когда внедрение NoSQL происходит в квалифицированной команде, мало что показывают. Потому что те команды способны написать свою RDBMS и вовсе с нуля; в таких проектах ведущая роль в успехе проекта принадлежит команде, а не монге. S>Для простого девелопера/стартапа/менеджера это означает, что пытаться воспроизводить опыт одноклассников — самоубийство. Там, где вы читаете "они взяли монгу, подпилили, и у них всё получилось", я читаю "они взяли мегакрутых перцев, и полгода пилили решение для трёх видов операций". Чтобы реплицировать их опыт в своём проекте, надо брать не монгу, а нанимать чуваков того же уровня. Что может обойтись значительно дороже ентерпрайз лицензии на MS SQL Server.
Хыхы, ты забываешь самый нормальный вариант, на котором как раз сейчас и работает большая часть веба (правда пока, по историческим причинам, на базе sql, но это меняется) — когда команда этих самых настоящих профи пишет движок (работающий с nosql БД), а потом этот движок используют в готовом виде в тысячах разных проектов.
_>>Вообще то CAS как раз обычно применяют для ускорения, т.к. при этом можно избежать блокировок. ))) Хотя там есть свои нюансы с быстродействием... Вообще это большая и популярная тема. ) S>Вы пытаетесь переносить подходы для межпотоковой синхронизации на ccNUMA архитектуре в мир распределённых приложений.
Этот вопрос никак не завязан на распределённость, а связан как раз с вопросом конкурентного доступа к ресурсу (причём внутри одного приложения — СУБД).
Собственно про вопросы связанные с распределённостью мы вообще ещё не говорили. Видимо потому, что тут вообще все sql решения в глубокой заднице. Т.е. даже если извратиться и наковырять руками шардинг sql БД, то всё равно никакого аналога инструмента типа map/reduce там не просматривается.
_>>А я где-то писал, что собираюсь писать банковское ПО на монге? ))) S>Ну вы же мне тут втираете, что лёгким движением руки приделаете ACID к монге. А я вам пытаюсь объяснить, что этот ACID будет тормозным убогим подобием тёплого лампового ACID из мира SQL. Если вам не нужен ACID — вам повезло, можно хранить данные в чём угодно. Вам запросто может хватить вообще голой FS, безо всякой СУБД. А если таки нужен, то я бы крайне не советовал велосипедить свой. Кроме случаев, когда это и есть ваша ключевая компетентность.
Какая-то путаница и вообще по nosql и по моему мнение относительно этого. Хотя я вроде как достаточно чётко его высказывал. Ладно, сформулирую в последний раз максимально ясно и по всем возможным вариантам:
1. ПО с требованием гарантий, которые плохо ложатся на любую nosql схему. Можно реализовать через:
— slq БД — это их естественная ниша.
— nosql с дополнительной надстройкой реализации ACID, имеет смысл только если становится критически важна автоматическая масштабируемость (т.е. случай огромных сервисов). Для одиночного сервера очевидно менее эффективно sql решения.
Т.к. лично я не занимаюсь созданием социальных сетей т.п., то мой личный выбор здесь sql БД.
2. ПО с требованием гарантий, которые нормально ложатся на какую-то nosql схему (на мой взгляд сюда попадает огромная часть современного веба). Можно реализовать через:
— slq БД — главное преимущество в автоматическом сохранение гарантий даже при изменение модели.
— nosql — заметно более высокое быстродействие (т.е. меньше расходы на железо) и автоматический шардинг из коробки, удобная (естественная) организация данных.
Лично мой выбор в данном случае за nosql решениями, т.к. при правильной реализации (а уж тем более в случае использования готовых движков) они очевидно лучше.
3. ПО без требований гарантий. Можно реализовать через:
— slq БД — идиотизм, т.к. напрасная трата ресурсов.
— nosql — естественная ниша этих СУБД.
Понятно, что здесь я тем более за nosql решения, как и наверное любой вменяемый специалист.
_>>Если реально нужна SQL БД с ACID транзакциями и т.п. то зачем трогать монгу? ))) Только вот на практике это как раз не особо часто требуется, а sql используется скорее по историческим причинам (просто ничего другого раньше не было, да и сейчас ещё не все успели изучить современные инструменты). S>Ок, давайте перейдём от технических вопросов к вопросам проектирования. ACID выражает интуитивное представление о корректной работе программы. Это то, чего ожидают все клиенты, если с ними не обсуждать иного. S>Как вы предлагаете проводить анализ требований к консистентности — т.е. как вы узнаете, какими инвариантами можно пожертвовать?
Поведение программы и наличие ACID транзакций в СУБД — это не особо связанные между собой вещи. Можно зафиксировать поведение и сделать к нему десяток разных реализаций (как на базе sql БД, так и на базе nosql).
Здравствуйте, Sinclair, Вы писали:
S>Нет, просто вы посмотрели на цены в $1300 за сервер без дисков и обрадовались. Добавите диски в ваш DL380 — и он вам встанет в половину R920. А чтобы порвать R920 по производительности, вам придётся зарядить штуки четыре таких DL380. Это если пренебречь потерями на синхронизацию между нодами.
Пока что я вижу демонстрацию дикой некомпетентности с твоей стороны. Т.к. вроде бы специалист в этой области (работает с сотнями чужих серверов и т.п.) называет хайэнд сервер мейнстримом и утверждает что сервер с ценой в 1000-2000 баксов умрёт от малейшей нагрузки (хотя AndrewVK указал, что весь rsdn спокойно работает на таком сервере). А при этом совсем не специалист типа меня (который может максимум заказать себе пару подобных железок для нужд своей компании) высказал оценки как раз полностью соответствующие реальности.
_>>Уже же вроде обсуждалось здесь. Redis — это не кэш, т.к. хранит данные на диске (хотя это и можно отключать). Пример кэша — это memcached, который действительно живёт только в оперативной памяти. S>Не важно, где кэш хранит данные. ISA тоже хранит их на диске, что не делает из него СУБД. Важна функциональность.
Вот именно, что важна функциональность. И по ней, по своему предназначению, Redis — это СУБД. Не смотря на то, что некоторые ммм специалисты предпочитают использовать его в роли кэша (вместо специально предназначенных для этого инструментов). И разницу в этой функциональности понять очень легко: форумы работающие на Redis'е (без всяких других СУБД) существуют (и кстати летают), а форумов работающих на memcached не существует.
Здравствуйте, AndrewVK, Вы писали:
S>>А на машинке за $1000 вы ничего интересного захостить не сможете — она умрёт быстрее, чем вы задеплоите первую версию. AVK>Антон, ты не поверишь сколько сейчас стоит та железка, на которой работает этот сайт — в районе 1500 баксов.
О, а можно ещё уточнить, сколько раз в год меняется схема БД форума rsdn? ) Будет очень полезная информация для завершения данной дискуссии... )
Здравствуйте, alex_public, Вы писали:
_>Чего чего? ) Вот мы храним в блобах некие сложные объекты и хотим получить из БД все строки, в которых одно из полей данного объекта имеет определённое значение. Как будет выглядеть такой запрос в sql БД? ) Естественно не прибегая к нестандартным расширениям, типа json в PostreSQL.
select * from values where value like '%"fieldname":"value"%'
Кандидатов фильтруем и отбрасываем.
_>Хранить вектор в блобе — это бред, который подходит только в очень редких случаях, когда с данными не надо делать никаких операций (кстати, по сути как раз случай БД ключ-значений ).
У вас раздвоение личности? Вы одной рукой выступаете за хранение вектора в блобе (NoSQL), а другой — против.
_>ОК, давай перейдём к практике. Вот допустим возьмём этот форум (rsdn) — сколько раз в год меняется его схема БД? )
Не схема, а требования к консистентности. Этот форум уже реализует ACID, поэтому мы не особенно ожидаем усиления требований к консистентности.
_>Хыхы, ты забываешь самый нормальный вариант, на котором как раз сейчас и работает большая часть веба (правда пока, по историческим причинам, на базе sql, но это меняется) — когда команда этих самых настоящих профи пишет движок (работающий с nosql БД), а потом этот движок используют в готовом виде в тысячах разных проектов.
Ну как же. Я вам ровно про этот вариант и толкую — команда самых настоящих профи пишет движок, а потом его используют. Например, MS SQL Server пишут очень грамотные чуваки.
Postgres пишут очень грамотные чуваки. А любители рожают уродцев, независимо от количества SQL в них. JSON в Postgres — это правильный NoSQL. XML support в SQL Server — это правильный NoSQL. Поддержка hadoop в SQL Server — это правильный NoSQL.
Правильный NoSQL отличается от неправильного тем, что мы начинаем с корректной реализации, и улучшаем её для определённых операций. А не отказываемся нафиг от всего, чтобы потом мучительно переизобретать транзакции на основе CAS и прочую чушь.
_>Собственно про вопросы связанные с распределённостью мы вообще ещё не говорили. Видимо потому, что тут вообще все sql решения в глубокой заднице. Т.е. даже если извратиться и наковырять руками шардинг sql БД, то всё равно никакого аналога инструмента типа map/reduce там не просматривается. Там, вообще-то, местами есть и более эффективные инструменты.
_>1. ПО с требованием гарантий, которые плохо ложатся на любую nosql схему. Можно реализовать через: _> — slq БД — это их естественная ниша. _> — nosql с дополнительной надстройкой реализации ACID, имеет смысл только если становится критически важна автоматическая масштабируемость (т.е. случай огромных сервисов). Для одиночного сервера очевидно менее эффективно sql решения.
Для кластера, я вас разочарую, это будет ещё менее эффективно.
_>2. ПО с требованием гарантий, которые нормально ложатся на какую-то nosql схему (на мой взгляд сюда попадает огромная часть современного веба). Можно реализовать через: _> — slq БД — главное преимущество в автоматическом сохранение гарантий даже при изменение модели. _> — nosql — заметно более высокое быстродействие (т.е. меньше расходы на железо) и автоматический шардинг из коробки, удобная (естественная) организация данных. _>Лично мой выбор в данном случае за nosql решениями, т.к. при правильной реализации (а уж тем более в случае использования готовых движков) они очевидно лучше.
_>3. ПО без требований гарантий.
ПО без требований гарантий можно вообще не реализовывать. Просто на каждый POST ваша форма будет говорить "200 ok", а на каждый GET — "404 Извините, наверное данные ещё не синхронизованы".
_>Поведение программы и наличие ACID транзакций в СУБД — это не особо связанные между собой вещи. Можно зафиксировать поведение и сделать к нему десяток разных реализаций (как на базе sql БД, так и на базе nosql).
Не надо юлить. Отказ от ACID — это вполне конкретное, наблюдаемое поведение. Вот вы интервьюируете заказчика, он вам рассказывает функциональные требования, вроде "есть функция поиска вариантов размещения в гостинице; на входе — географическая привязка; даты вселения/выселения; набор проживающих — количество взрослых, и возраста для N детей. На выходе — список свободных номеров на эти даты, удовлетворяющих заданным критериям". Вы в какой момент будете его спрашивать "а можно мы будем иногда показывать и номера, не подходящие под запрос"?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, koandrew, Вы писали:
K>Фича эта — гениальная штука. Никогда ещё деплоймент обновлений, модифицирующих схему БД, не был настолько простым.
Неужели вы ничего не слышали о миграциях для БД до появления оных в продукте от Microsoft? Да и сделать их так, как они сделаны в Entity Framework, мог только упоротый индус; например, прикрутить их migrate.exe к билд-серверу по силу только людям с определенным складом ума.
Microsoft до сих пор считает, что публикация непосредственно из Visual Studio -- это единственно правильный вариант. На деле же за это расстреливают у заднего колеса штабного УАЗа.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, alex_public, Вы писали:
_>О, а можно ещё уточнить, сколько раз в год меняется схема БД форума rsdn? ) Будет очень полезная информация для завершения данной дискуссии... )
Разработка РСДН — в принципе крайне нерегулярная штука. Но когда она ведется, то изменение схемы БД не такая уж и редкость.
Мы уже победили, просто это еще не так заметно...
