• 0
    А что с управлением состоянием? Просто все очень хорошо с реюзом пока у компонентов не появится внутреннего состояния, а вам не понадобится history management.
    React, Web Components, Angular и jQuery — друзья навеки. Универсальные JavaScript-компоненты
  • –2
    Ну так научитесь именовать чтоль переменные тоже правильно, а не только типы. Или вы аппелируете к тому, что разработчики стандартной либы более правильно именуют типы, чем разработчики вашего проекта переменные?
    Ключевое слово «var» в Java: пожалуйста, только не это
  • +4
    И все же джависты не умеют в корректный нейминг
    FileInputStream theSavingStream

    Теперь я гораздо более хорошо понимаю почему вы считаете, что var это плохо
    Ключевое слово «var» в Java: пожалуйста, только не это
  • 0
    А если у вас две переменные (одна InputStream, другая OutputStream), вы как их различать будете? По имени или будете каждый раз бегать глазами к определению переменной?
    Ключевое слово «var» в Java: пожалуйста, только не это
  • +4
    Я не понимаю, почему ошибки не полезут, если мы оставим тип явно. Я также не понимаю, почему ошибки для кейса var будут менее понятными, чем ошибки для кейса createStream().getIP() (т.е. когда мы объединяем цепочку вызовов).
    Ключевое слово «var» в Java: пожалуйста, только не это
  • +2
    Что именно за поток возвращает функция?

    А зачем вам это знать? Я правда не понимаю, объясните
    Я уже не говорю о случаях, когда код был порефакторен кем-то другим (например, человек заменил значение, которое openStream() возвращает — а var остался).

    И что случится плохого, если другой человек поменял возвращаемый тип метода openStream?
    Вы, кстати, не думали о таком концепте: иногда необходимо, чтобы тип переменной был жестко связанной с типом выражения? Например в c++ есть decltype.
    Ясно также, что по-хорошему нужно точнее именовать метод. Но, на мой взгляд, подобные вещи будут приводить к тому, что имена переменных и функций начнут включать в себя ту самую «воду», которая до этого обозначала тип. Особенно когда речь идёт о больших проектах.

    Т.е. по вашему лучше определение переменной в видеFileInputStream fos = ... нежели var inputStream = ...?
    Ключевое слово «var» в Java: пожалуйста, только не это
  • +2
    У var есть польза, но я понимаю людей которые не могут ревьювить шарповый код с обилием varов. Банально разница в том, к какому подходу привык человек. Есть подход, основанный на концепции "важен код, т.е. действия, которые мы совершаем" и есть подход, основанный на концепции "важны типы, т.е. то, с чем мы работаем". Оба подходы имеют право на жизнь и более того, разные подходы по разному ложатся на разные задачи.
    Но прикол в том что отсутствие varа и тех же лямбд (ранее) мешал следовать первому подходу. Тогда как в грамотных руках var и лямбды делают код более читабельным, а не наоборот.
    Можно сравнить код с статьями/книгами. Слишком много воды — трудно уловить суть. Слишком мало воды — мозг либо отвык, либо просто не может слишком долго концентрировать на важных вещах. Оптимальный баланс найти трудно.
    Ключевое слово «var» в Java: пожалуйста, только не это
  • 0
    Да, пожалуй случай когда NetUtils возвращает FileOutputStream это действительно весьма странный кейс, когда было бы неплохо увидеть, что тип переменной таки FileOutputStream.
    Но вообще для меня видится довольно странным заявление, что var приносит мало пользы и больше вреда. Это где-то аналогичное тому, что говорить что понижение типа это вредно (типа так: OutputStream unbufOut = NetUtils.getOutputStream(sock);). Зависит от случая к случаю.
    Вообще, в строке приведенной автором для примера я вижу две проблемы корректного именования и проблему того, что зачем-то метод возвращает максимально специфичный класс. Видать джависты не умеют в корректный нейминг и ООП.
    Ключевое слово «var» в Java: пожалуйста, только не это
  • +3
    Во-первых, это зависит от того, зачем вам это дерево нужно. Например, в случае с комментариями к статье — гораздо проще к каждому комментарию добавить айдишник статьи и уже потом сформировать дерево комментариев на приличном языке программирования.
    Во-вторых, нужно учитывать что у документа есть ограничения на максимальный размер
    В-третьих, нужно учитывать что атомарный апдейт документа — это блокировка работы со всем деревом внутри документа.
    В-четвертых, чем не устраивают графовые бд для деревьев?
    MongoDB хранение деревьев
  • –1
    Т.е. только отрисовка UI? А альтернативой им будет C++ под кастомную платформу, более дорогие и редкие разработчики и сложности при разработке связанные с тем, что нету эмулятора устройства? Ну в данном случае это действительно хороший выбор по дешевизне разработки.
    JavaScript и Nginx = nginScript, а HTTP2 в придачу
  • –1
    Ну да, еще нужно критическое состояние. По-моему количество веб-сайтов уже является примером критического состояния.
    JavaScript и Nginx = nginScript, а HTTP2 в придачу
  • +2
    Ну давай пройдусь по пунктам:

    1. Приложения в браузере. Ну… Эта, давайте я не буду напоминать лишний раз о том, что приложения в браузере не дотягивают до уровня десктопных?
    2. Node.js — изоморфные приложения, избавление от необходимости дублировать логику, серверный рендринг страниц и прочие плюшки. Популярность понятна.
    3. Операционная система на js? NodeOs что-ли? Это там где взяли linux, выкинули bash и поставили node.js? Мне чё, сделать brainfuck os, чтобы показать абсурдность ситуации? Или может имеются в виду всякого рода веб-оси, которые прикольны только как концепт, но ничего сделать не позволяют?
    4. Плагины для браузера на js? Логично их писать на js, раз веб пишется на js. А давать возможность писать их на C++ — упадет, поломает, уязвимости всякие.
    5. Браузер на JS? Ну давайте, покажите мне браузер на js. Я например пользуюсь Вивальди, у которого UI сделан на react. Да, UI написан на javascript. Глюки пока списываю на то, что браузер не вышел в релиз, однако некоторые артефакты весьма специфичны для глюкавых html/css. Если подключиться к самому вивальди через developer tools, то можно увидеть засранную консоль от ошибок типичных для языка с динамической типизацией. Однако это UI, сам браузер написан на другом языке.
    6. Десктопное приложение на JS? Ну, в эпоху когда люди хотят все онлайн, то написать веб-приложение, а потом упаковать его node-webkit выглядит логичным решением. Или нет?
    7. IDE на JS? О да, я даже знаю одну такую — LightTable. Правда она написана на clojurescript. Просто у людей, которые её писали был выбор между clojure (компилится в java) и clojurescript (компилится в javascript). Так уж получилось, что писать UI оптимальнее с использованием html/css/js. Будет WebAssembly — будет транскомпиляция туда. Работает кстати хорошо, быстренько вроде. Правда консоль опять же засрана типичными ошибками для языков с динамической типизацией.
    8. Микроконтроллеры на JS? А почему вы уверены, что их не фронтендеры программируют? И вообще, как насчет python, rust? Это просто удешевление рынка игрушек для гиков. Гугление показало, что в тех микроконтроллерах характеристики лучше, чем у моего первого компьютера (если что, я молод душой и телом). Рост характеристик позволил писать программы на языках с динамической типизацией. А я таки уверен, что среди фронтенд разработчиков много людей, которым интересны такого рода игрушки. Спрос есть, возможность есть — банальные законы рынка. Но если рассматривать не игрушечный бизнес, то сколько компаний пишут софт для микроконтроллеров на javascript?
    9. Конфиги на JS? Внимательное чтение статьи намекает, что это не javascript, а всего-лишь диалект. Кроме того, ну а чем javascript не хороший язык для скриптов? Ведь он для них и задумывался. Вот приложения на нем писать больно, да, а скрипты норм.

    Вообще, еще можно вспомнить mongodb и couchbase, как базы данных, в которых юзается javascript для юзерских скриптов. Но все это не важно. Веб порождает спрос на javascript разработчиков, javascript разработчики порождают спрос на плюшки, с которыми они могут работать. Вопрос заключается в том, как быстро сойдет спрос на javascript разработчиков, когда появятся реальные альтернативы, а не транскомпиляторы недоделанные?

    Давайте представим гипотетическую ситуацию. Какая-нибудь компания стартует большой проект. У компании есть выбор между двумя языками программирования: каким-нибудь из хороших и javascriptом. При сравнении эти языки оказываются одинаковыми по дешевизне разработки, количеству разработчиков, количеству библиотек и прочее-прочее в рамках этого проекта. Как много компаний вы знаете, которые выбрали или пожелали бы выбрать javascript потому что ну это же javascript — клёвый язык программирования; и разработчики под него хорошие и толковые; и завершим мы проект пораньше, потому что язык такой хороший?
    JavaScript и Nginx = nginScript, а HTTP2 в придачу
  • 0
    Я надеюсь WebAssembly и спрос на производительный веб избавит нас от подобного будущего. Распространеность этого языка обусловлена ростом веба и соответствующим спросом на разработчиков, умеющих программировать под единственый язык, заимплеменченный во всех браузерах.
    JavaScript и Nginx = nginScript, а HTTP2 в придачу
  • +1
    fyudanov, matiouchkine
    У каждого из вас просто-напросто разная практика. На деле, множество аутсорсинговых компаний не заморачивается качеством. Как правило долгосрочную поддержку они не оказывают, продукты педалятся быстро, умирают тоже быстро. В итоге в долгосрочной перспективе качество кода не важно. А в краткосрочной перспективе очень сложно объяснять почему нужен рефакторинг. Зато плохое качество кода приводит к тому, что проект не заканчивается раньше чем нужно, что является хорошим фактом с финансовой точки зрения кампании. Ну и оправдываться в стиле «очень много функционала, каждая новая фича пишется труднее» — это нормально и привычно всем. В некоторых компаниях очень заморачиваются на эстимейты, поэтому сделать больше, чем нужно — это неприемлемо для менеджмента.

    Вообще, на разной длительности проекта и с ростом размеров кода нужно придерживаться разных правил. Глупо писать свою инфраструктуру/фреймворк когда вам нужно реализовать одну-две апих. И глупо не писать, когда апих становится много. Прикол заключается в том, что многие разработчики не понимают концепт «рефакторить все время», в итоге получаем легаси и говнокод во все бока.

    Также стоит отметить, что отрефакторить что-то за один раз не всегда получается. А пока ты занимался чем-то другим другой разработчик приходит и дописывает еще херни.
    Что такое красивый код, и как его писать?
  • 0
    Либо выключенный джаваскрипт на мобильном браузере )
    Functional C#: работа с ошибками
  • 0
    Если рассматривать в отрыве от валидации, то исключения и ifы просто вносят дополнительную сложность в код, делая его менее линейным и более объемным. Та же Maybe монада — это всего-лишь фокус, чтобы запрятать nullcheckи и сделать код линейным и менее объемным. Никакой магии, никакого профита кроме читаемости и линейности кода. В принципе, это всего-лишь разные подходы для управления control flow. В разных ситуациях получается разные по читаемости код.
    Functional C#: работа с ошибками
  • +3
    Для начала, нужно понимать, что есть разного рода ошибки. Есть исключительные ситуации, а есть валидация. Исключительные ситуации очень похожи на валидацию, но это как разница между интерфейсом и абстракным классом (особенно в C++) — она на уровне семантики (смысла кода). Исключительные ситуации нужны для проверки корректности работы системы. Валидация нужна для проверки корректности данных от пользователя.

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

    Теперь рассмотрим другой пример. После редактирования сущности сервер должен в любом случае провалидировать корректность данных (даже если такие проверки есть на фронтовой части). При этом пользователь должен получить список всех ошибок, иначе его будет раздражать процесс работы с системой. Но вы можете бросить только одно исключение, которое увидит пользователь. Поэтому тут исключения враг. В данном случае очень хорошо работает подход с набором различных независимых валидаторов и собиранием результатов их работы. Тот же ASP.NET MVC/Web API с их ModelState.IsValid — это классический пример данного подхода. При этом при самой валидации нам не нужен стектрейс, а иногда еще и даже вреден — вы же не хотите, чтобы до юзера дошла информация о стектрейсе приложения?

    Но, у подхода с набором различных независимых валидаторов есть проблемы.

    Первая проблема: они независимы друг от друга.
    Пример: у вас есть поля password и confirmPassword. На первое поле навешана валидация «пароль должен быть сильным», на второе поле навешана валидация «confirmPassword должен совпадать с password». Показывать обе ошибки немного странно.

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

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

    Прикол заключается в том, что бросить исключение это легко, привычно и требует меньше действих, поскольку интегрировано в язык. Писать набор валидаторов или Result/Validation фокусы — непривычно, да и не всегда так явно и очевидно в рамках языка. Поэтому пока что разумным подходом является смешивание подходов. Но не стоит забывать о том, что требования рано или поздно могут измениться, а времени на рефакторинг не будет.
    Functional C#: работа с ошибками
  • +2
    Возможно вам просто привычнее стандартный подход. На деле пример в статье очень неудачный для пропаганды: он очень простой. В данном примере есть разница между тридцаткой строк почти линейного кода и десяткой строк совсем линейного кода. Поэтому безоговорочно выигрывает привычный код.
    В случае, когда кода гораздо больше и необходима мультивалидация (т.е. нужно вернуть все ошибки) данный подход является более читабельным. По крайней мере, я самостоятельно пришел к такому подходу.
    Functional C#: работа с ошибками
  • +1
    а) файловые системы не любят когда файлов слишком много. Базовый совет по огранизации file storage на основе файловой системы — взять guid или хеш и его части использовать как вложенные поддиректории.
    б) много мелких файлов — гарантия фрагментации
    в) файловая система медленная, поверх неё нужна еще in-memory прослойка. Тупо mapить такое количество файлов не выйдет — их слишком много и они мелкие. Не говоря уже о том, что часть данных не будет помещаться в ОЗУ.
    г) key-value хранилища бывают разные, некоторые с поддержкой транзакций

    Бенч увы не приведу, это только общие рассуждения.
    Как работает реляционная БД
  • 0
    Нет, я не утверждаю такого. Я просто хотел сказать, что распарсить запрос — это не вся работа по оптимизации, которая может быть проделана
    Как работает реляционная БД
  • 0
    В общем, как и любая программерская дискуссия рано или поздно мы упираемся в наш собственный ограниченный опыт и наши бенчи, написанные под наши кейсы. По-моему тут мы заходим в тупик и дальше дискутировать бессмысленно, ибо никто никому ничего не докажет )
    Как работает реляционная БД
  • 0
    Есть таблица, она должна быть не in-memory и персистентной. В неё нужно вставлять много записей временами. MVCC — это дополнительный оверхед на ресурсы, не IO диска, так память. Локи это тоже дополнительный оверхед на ресурсы. Без локов, без mvcc, руками — невозможно в SQL Server, но даст отсутствие лишнего оверхеда. Я об этом говорю, о избавлении от оверхеда вообще
    Как работает реляционная БД
  • –1
    Понимаете в чем фишка. Большая часть программистов, которая работает с базами, делает учетные системы в том или ином виде. А для них сценарии, где пригодны NoSQL базы, ну крайне специфические.

    У меня фишка прикольнее. Я долго не мог осознать как писать решения на чистых key-value storах. Для меня это было на грани «вы че ебанутые, а как транзакции, а как же атомарность, я че руками должен это делать все?». Потом со временем в голову начало приходить, что я могу последовательно переписывая многие вещи отказаться от многих кейсов использования sql. При этом получить профит. Хотя это и трудно моментами продумать. Но я понимаю о чем вы говорите.
    Как работает реляционная БД
  • 0
    И что? Это вовсе не означает что будет реальная запись на диск. Вы в курсе как buffer pool работает?

    Мм, т.е. вы таки хотите сказать что in-memory MVCC быстрее чем запись вообще без локов на свежезаписанные записи?
    Как работает реляционная БД
  • 0
    Почти все NoSQL базы занимают промежуточное положение. Они вроде как хранилища, но без транзакционности, с другой стороны кеш, но без возможности сброса.

    А что если этого достаточно для реализации транзакционности руками?
    Как работает реляционная БД
  • 0
    Вам очевидно, что денормализация требует больше ресурсов при записи?
    Вам очевидно, что денормализация требует больше кода?
    Вам очевидно, что денормализация — не гарантия более быстрых запросов?

    Интересно пишешь. Первые два утверждения абсолютные, третье не абсолютное. «Не гарантия» — т.е. может не быть, а может и быть.
    И отсюда у тебя вывод что в 100% случаев денормализация это вредный совет (да, я там фиксировал на 100%, но вы же не поправили «в редких случаях»). Если бы третье было бы абсолютным, то в совокупности с другими утверждениями по законам логики вывод был бы правильным. Но третье утверждение не является абсолютным (и ты это понимаешь), поэтому вывод неправильный.
    Как работает реляционная БД
  • 0
    Механизм обеспечения целостности кеша — сброс и пересбор из хранилища. Сброс кеша сложная задача, но решаемая.
    Механизм обеспечения целостности в хранилище — транзакции и проверки. Это тоже сложная задача, но тоже решаемая.

    А механизм обеспечения целостности кеша и хранилища вместе? На каждую стартующую транзакцию сбрасывать кеш и блокировать его, пока транзакция не завершится? Я только это вижу в качестве решения противодействию нахождении в кеша старых данных.
    Как работает реляционная БД
  • +1
    Если исключить требования уникальности, то будут проданы два билета на одно место и систему быстренько поменяют

    Не надо исключать требование уникальности, я говорил про исключение процесса бронирования.

    С точки зрения UX вообще нельзя ничего блокировать. Поэтому оптимистичная блокировка (легковесный аналог MVCC) + автомерж изменений при конфликтах. Но к тому что делается в базе не имеет никакого отношения.

    По-моему процесс мерджа подразумевает три источника данных: base, this, remote. А это значит, что вам нужно хранить историю изменений. А это дублирование механизмов, заложенных в бд, нет?.. Кроме того, автомердж без подтверждения юзера — плохое решение с точки зрения UX.
    Как работает реляционная БД
  • 0
    Ну, да, бронировать тоже нужно атомарно. Просто прикол в том, что в итоге атомарность обеспечивается и приложением, и сервером базы данных. Получается некоторое дублирование.
    Как работает реляционная БД
  • –1
    А денормализация бесплатная чтоли?

    Руками написанная денормализация иногда бывает почти бесплатной. Иногда она бесплатная только на фоне оверхеда от материализованных вьюх
    Как работает реляционная БД
  • –1
    Про то, что есть кеширование планов не знает только ленивый. Native Stored Proc работает только с memory таблицами.
    Как работает реляционная БД
  • –1
    Эм? Если ты хочешь исключить бронирование билета из процесса покупки, то ничего страшного не произойдет. Create Unique решит проблему одновременной покупки билета. Просто твоя система будет говном с точки зрения UX, но это же ничего страшного, да? Зато ты не будешь изобретать блокировки, которые уже релизованы в твоей РСУБД.

    Не отмазывайтесь, отвечайте на вопрос, как вы будете обрабатывать ситуацию возможности открытия двумя разными юзера одной сущности на редактирование? Что вы будете делать, чтобы не изобретать блокировки и mvcc, кроме как положите на эту ситуацию?
    Как работает реляционная БД
  • 0
    Или вы заставите одно из них ждать пока 15 минут другого закончатся?

    Да, в этом смысл бронирования. В том, что другой юзер вообще не увидит забронированный билет. А юзер, который забронировал билет — будет видеть время, которое у него осталось для совершения оплаты билетов. Это UX-требование, это то как должна работать система уважающая пользователя

    Вы не понимаете, что только что попытались изобрести механизм блокировок, который уже есть в любой РСУБД? При этом надо будет написать немало кода чтобы реализовать ваш сценарий.

    Да-да, я изобрел механизм блокировок, который есть в любой РСУБД. И это UX-требование и это блять удобно для пользователя. И этим UX-требованием я хотел продемонстрировать, что механизмы блокировок, которые реализованы в бд нужно дублировать мануально в случае существования таких требований.
    Поэтому вместо стандартных блокировок можно использовать то хранилище, которое не навязывает свой механизм блокировок, а позволяет делать что угодно без лишних проблем и просадок по перфомансу. Встречный вопрос: есть сущность в бд, её могут случайно открыть два пользователя конкурретно на редактирование. Как вы будете обрабатывать это и возможные последствия этого?

    Ссылки в студию.

    neo4j.com/docs/stable/query-create-unique.html. Пойдет?
    Как работает реляционная БД
  • –1
    Это лишь означает, что вы не умеете работать с кешем. Если вы сбрасываете кеши вовремя, то не будет ни грязных, ни устаревших данных.

    Блять, ты вообще читаешь что ты пишешь? Ты говоришь о трудностях обеспечения согласованности и целостности nosql бд и при этом говоришь о легкости обеспечения согласованности двух независимых хранилищ. Как это?

    SQL Server

    Тоже мне. серьезный взрослый движок.

    И как часто встречается такая проблема в OLTP? На моем опыте — один из ста.

    На твоем опыте.

    Если речь идет об оптимизации джоинов, то почти нет.

    И как у SQL Serverа с материализованными вьюхами, содержащими left joinы? А никак, нельзя такие. И множество функций юзать тоже нельзя в материализованных вьюхах.

    Конечно могу. Я неоднократно оптимизировал приложения путем убирания ручной денормализации.

    Господи, да никто не спорит, что денормализированная бд может слоупочить. И никто не спорит, что неправильный дизайн тоже может слоупочить. Но я просил пруфы, что денормализация это вредный совет в 100% случаев. Меньше не надо, а то по совокупности моих претензий может выйти что юзать не sql решение.

    Oracle, SQL Server они умеют read commited snapshot. Фактически не навешивает блокировки при записи. Насчет DB2 не уверен

    SQL Server снепшоты умеет через tempdb. Я хотел снять нагрузку с бд удалив writer-writer lock, мне предлагают юзать tempdb, который тоже вполне себе нагружает бд. Это не то, что я хочу от бд. Я хочу чтобы она позволила мне вставить несколько тысяч записей конкурентно, тратя ресурсы только на реорганизацию индексов. Это плата за умность реляционных бд — они не дают тебе сделать того, в чем ты уверен. А я уверен, что никто не будет трогать мои новые записи до того, как я завершу их вставку, поэтому мне лок на них не нужен.

    В SQL Server есть partition switching

    У SQL Server 2008 лимит на количество партиций был в тысячу. Сейчас вроде повыше, но все равно константа. Что как бы позволяет плясать, но не очень сильно и хорошо.

    Названия в студию. А еще крайне желательно описание как они это делают

    Вы знаете, тут меня подловили. Я понадеялся на redis, у которого есть стандартная возможность добавлять в список, но там ничего не сказано по поводу того, насколько хорошо обрабатывается конкурентность (так что можно только надеяться на то, что там все ок). Понадеялся на другие key-value stores — так там стандартное решение это юзать key ranges (а это подходит под эти цели, но концепт немного другой). Ну или обычно это не спефика для решений, которые должны быстро работать и шардиться. Так что сорри, тут обманул.

    Крайне редко, именно поэтому сценарии специфические.

    Они для вас специфические. Вам не кажется, что специфические для вас сценарии в других проектах могут происходить чаще? Или хуже того, что с развитием сложности проектов специфичные решения станут все более и более частыми?
    Как работает реляционная БД
  • +2
    В любой достаточно адекватной системе есть механизм бронирования. Например, как работает заказ билетов на поезд:
    1. Юзер выбирает место, оно бронируется под него на 15 минут
    2. Юзер втыкает минуту, выбирает еще одно место, оно бронируется под него на 15 минут
    3. У юзера остается 14 минут, чтобы успеть оплатить оба билета (или 15 минут, чтобы успеть оплатить только второй билет)
    4. После оплаты юзером билеты считаются купленными юзером.
    5. По истечению времени билет возвращается в свободные билеты.

    Это я к тому, что мир на самом деле сложный. Я только что привнес просто дополнительной сложности, извините.

    Касательно вопроса — а как таки сделать уникальность привязки места к юзеру? Я только что пошел в документацию Neo4j (бд которую я в первый раз в глаза вижу) и нашел несколько способов это сделать, помимо очевидных костылей типа двухфазного коммита.
    Как работает реляционная БД
  • +1
    Запрос парсится ровно один раз.

    Ага, и сразу же превращается в бинарный код, готовый для исполнения. Как давно взрослые и серьезные движки такому научились и насколько хорошо они это делают?
    Как работает реляционная БД
  • 0
    Диссонанс у вас от того, что вы не понимаете задач кеша и хранилища, тем более что некоторые решения для кеширования позиционируются как NoSQL базы данных.

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

    Во взрослых движках — сколь угодно много.

    Покажите мне взрослые движки, пожалуйста. Я сейчас про кейсы типа «к сущности можно привязать не больше n количества других сущностей, где n — число заданное в конфигурации этой сущности» (ну или хотя бы где n — константа) и прочие милые вещи.

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

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

    Далее в каждой серьезной БД есть материализованные представления, которые позволяют не нарушать целостность и поддерживать «денормализацию»

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

    Идеи про денормализованность — совершенно бредовые для OLTP.

    Это значит что в вашей практике не было необходимости делать денормализацию бд или вы готовы подкрепить подобные заявления чем-то?

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

    Прикалываетесь или как? Реляционная субд построена на идее индексов (да, можно сделать таблицу без кластерного индекса, я знаю). Индекс — это (key) — (included fields + primary key of value), т.е. key — value. Реляционная субд — это key-value, какие-то гарантии транзакционности и атомарности, а также query language, который не заставляет пересылать данные туда-сюда для того чтобы сделать joinы. Вопрос в том, насколько эффективнее реляционная субд по сравнению с мануальной обработкой всего этого.

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

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

    Вообще для key-value идеальное решение — файлы на диске. Ключ — имя, value — содержимое. Работает быстрее и надежнее любой базы.

    Чушь.

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

    Вы этой фразой переводите реляционные БД в область инструментов для прототипирования, нет?

    При этом во взрослых движках можно отключить и механизмы конкуренции

    Пруфы плиз. Меня интересует полное отключение writer-writer locking. Какие взрослые движки это умеют? Вообще у меня скаладывается впечатление, что ни один из нас не видит полноценно картину.

    Поэтому при прочих равных лучше выбирать SQL-базу и добавить кеш для скорости, чем писать тонну кода, чтобы хоть какое-то подобие согласованности поддерживать в nosql

    А когда проседает и выборка, и вставка, что делать? Тонны кода — это весьма громогласное утверждение, если вы пишете объемную систему.

    За исключением некоторых специфических сценариев.

    Вопрос в том, насколько часто у вас проявляются специфичные сценарии. А вообще, если был груб, то извините, моя злость на реляционные БД сопряжена попытками получить приемлемую производительность там, где было бы разумнее заюзать key-value хранилища вместо «детского» движка )
    Как работает реляционная БД
  • 0
    язык исполнения = языку общения — это lisp что-ли? Интересно, скиньте в личку. Не присоединюсь, но посмотреть интересно. Засирать не буду, конструктивную критику по возможности напишу.
    Парадигма ситуационно-ориентированного программирования
  • +4
    Потому что реляционная бд это универсальное решение, которое предназначено хоть как-то работать со всем чего от неё ожидают. Это цена универсальности.
    Key-value хранилище заточенно под определенные задачи. Любое заточенное решение по определению потенциально должно работать лучше чем универсальное решение. За конкретными бенчмарками можно сходить в гугл.
    Но вообще, если я вас не убедил, то ответьте на такой интересный вопрос: зачем на рынке появляются отдельные key-value хранилища когда уже 40 лет есть замечательные и восхитительные реляционные БД. И уж тем более, зачем люди меняют замечательные и восхитительные реляционные БД на унылые key-value хранилища, они чо упоротые?
    Как работает реляционная БД