Комментарии 10
Идея о том, что нереляционная база — это более простая и примитивная замена реляционной базы, не верна в корне. У разных видов баз просто разные ниши.
Я думаю в пятом пункте речь о том, что РБД реализуют наиболее удачное сочетание гарантий и ограничений по-умолчанию, включая такие гарантии, существование которых интуитивно допускается слишком многими разработчиками.
Например, многие привыкли, что БД должна поддерживать транзакционное изменение нескольких элементов данных сразу, и только потом узнают горькую правду о выбранной ими документно-ориентированной СУБД.
Абсолютно верно! С удивлением обнаружил, что нереляционные базы - это сложнее, чем реляционные т.к. умеют делать практически всё, что умеют реляционные и намного больше. Например, оказалось, что для удобного хранения данных в нереляционной базе недостаточно следовать принципам нормализации данных, а порой - нормализация даже вредна. Поэтому следуя YAGNI предпочтительно использовать реляционную БД
Тем людям, кто против сохранения временных меток в записях, обычно невозможно объяснить, зачем это нужно. Они же экономят байты работодателя
Я против сохранения непосредственно в записях. Если необходимо фиксировать изменения стейта объекта - так и надо это делать. А вот стоит у тебя только дата последней правки. Что было исправлено? Эта дата перезаписала предыдущую дату правки. А если ошибка была в предыдущие разы? Не стоит полагаться на утверждение что дата спасет от ошибки или поможет ее исправить. Не поможет. И Стейт восстановить не получится.
Дата последнего изменения это не дата создания. В статье именно речь про дату внесения записи в БД. Такая дата не перезаписывается. И не понимаю, почему Вы против даты изменения. Сохранение даты изменения во всех таблицах ничуть не отменяет истории стейтов или что там у вас... Но добавляет способ выбрать объекты изменённые в определённом промежутке времени и ещё много чего полезного.
Ээ. А история изменения стейта это разве не даёт? А дата первой записи изменений стейта это разве не дата создания объекта? Все же, Появление поля автодаты в модели стоит объяснять с точки зрения бизнес задач модели. Понимаю, когда поле появилось по причине денормализации таблиц из за проблем со скоростью получения записей. Понимаю, если действительно есть бизнес-кейс на это, например, структура модели должна совпадать со страной сторонней базой управлять которой мы не можем но данные оттуда хотим. Но например, Если есть uuid опять же непонятно зачем дублировать. А если - вляпаем дату и всем будет проще - нет не будет. Будет сложнее. Но, вероятно, не сейчас а сильно позже. У меня в старом проекте аж 4 поля автор, едитор, создано, исправлено. Спустя 9 лет они добавляют ещё одно полено в адский огонь под моим котлом. Не сильно, но добавляют.
На мой взгляд удобно хранить в основной таблице дату создания записи и при необходимости в отдельной таблице вести журнал изменений. Дата создания может понадобится и не придётся джойнить лишнюю таблицу. ИД и ТС для меня как два основных технических поля любой таблицы. А сэкономив в одном месте теряем где-нибудь в другом.
с плоскими файлами
Кажется, plain files должно переводиться как то по другому.
Отличная пища для размышлений, которая может помочь в споре с человеком, который считает, что нужно "тупо" следовать всем принципам))
Исключения из принципа YAGNI