Напомнило анекдот:
Поспорили терапевт с ветеринаром у кого работа сложнее. Спорили-спорили, не могут договориться. Ветеринар предлагает:
— Давай тестовый приём проведём?
— Давай!
— Ну вот представь, я пришёл к тебе на приём. Что бы будешь делать?
— На что жалуетесь?
— Э, нет! Так каждый дурак может!
Но квалифицированных специалистов (что в IT, что HR, что в управлении) — мало. Поэтому, в большинстве случаев, никто не следует разумным советам из статьи.
Я прекрасно всё понимаю: и про игрушечность примера и про разницу между итальянским и англо-саксонским конто (там, кстати, может быть ещё веселее, когда по разным счетам суммы ещё и в разных валютах — сам такое делал :)). Просто начал читать и как-то резануло. Потом втянулся :)
Правило согласованности может звучать так: перевод никогда не меняет общей суммы денег на счетах (такое правило довольно трудно записать на SQL в виде ограничения целостности, так что оно существует на уровне приложения и невидимо для СУБД)
Это не совсем так. Точнее совсем не так. Просто оно будет записано не в виде ограничения (CONSTRAINT), а в виде схемы данных, где сумма фигурирует один раз и к ней так или иначе «подвязаны» два счёта. Такой, классический «транзакционный» (не в смысле СУБД, а в смысле бухгалтерского учёта) вариант. Правда при такой схеме остаток (сальдо) по счёту не хранится, а требует вычисления каждый раз, когда он потребуется.
«Работы должны быть выполнены в соответствии с техническим регламентом»
Это вообще не цель и не задача. Это ограничение. Ну или поясните как именно вы собираетесь измерять «степень соответствия регламенту при выполнении работы»
«Презентация должна быть представлена в формате Power Point»
Это не цель и даже не задача (потому что в нём ничего не говорится о том для чего и/или как это должно быть выполнено). Это требование (нефункциональное).
«Уклон дороги должен составлять 6 %, а строительные работы — выполняться с учетом требований техники безопасности»
Это тоже требования (см. выше). Если уклон будет 2%% это лучше чем если он будет 12%%? В какую сторону должны быть направлены усилия тех, кто будет этот уклон формировать?
«В качестве образца используй прошлогоднюю презентацию»
Это вообще не несёт никакой смысловой нагрузки.
«В стандартную форму отчета внеси дополнительный столбец для выделения непредвиденных расходов»
Это более-менее похоже на цель, но она категорически не SMART (в том числе в части М — если столбцов будет внесено не один, а семь можно ли сказать что результаты превзошли ожидания?)
«Напиши объяснительную записку в свободной форме»
Опять мимо. Здесь вообще ничего измерить нельзя!
«Производительность оборудования к концу квартала должна достигнуть 80 %»
Под конец вам (или автору статьи) почти удалось. Почти, потому что не указано 80% от чего. От производительности на начало квартала? От максимальной производительности по итогам прошлого года? От проектной производительности?
В общем, судя по всему, все статьи про SMART которые вы видели были, мягко говоря, не очень… Так что погуглить, в данной ситуации, лучше вам!
А как вы в JSON будут поддержку N форматов делать, когда в начале был JSON с 1 полем, потом с 5, потом снова с 5 но другими, потому что кто-то удалил поле и добавили новое? Наверное вы хотите в коде поддерживать N форматов для одного blob поля? Спасибо, такое проходили, не нужно.
Никак не буду. С точки зрения БД они все одинаковые (потому что семантика существует только на стороне того кода, который на основании этих данных будет рендерить формы)
А как жить с EAV таблицей на 100 млн строк? Тоже 1 запросов поднимаете? И выборка на 10 строк отрабатывает за 6 секунд
Ну, если у вас несколько сотен тысяч форм…
Хотя 100 млн. это, вообще говоря, не много. В чём проблема поднять по индексам десяток значений атрибутов одного объекта (по его ключу) — вам виднее. По мне 6 секунд на 100 млн. записей (для значений, да и для объектов даже) — это не долго. Это ОЧЕНЬ долго.
Если вы не видите проблем, это не значит что их нет.
По вашим пунктам:
1. Если у вас формы с, максимум дюжиной элементов — да. По мне такие формы, скорее, исключение.
2. Можно да, а можно нет. А в данным случае вы будете это делать обязательно.
3. Никакой рефакторинг в данной ситуации вам не поможет. Максимум чего вы добьётесь — это регулярной уборки. Если вам нравится сначала раскидывать мусор, а потом регулярно его убирать — кто вам может запретить? Но на мой взгляд это довольно странная стратегия
4. Любой лог — это просто инструмент. Вы забываете про то, что он не сделает счастья автоматически. Но, повторюсь, если вам нравится всё время приводить в порядок разбегающийся зоопарк — это ваше законное право. В каждой избушке свои погремушки.
5. О разработчиках, которые будут эти поля заполнять и использовать
6. см. ответ на ответ 3. Помноженный на то, что вы в одном месте храните совершенно разные данные (в них нет никакой логической связи «по-вертикали»).
Что вы хотите услышать про EAV и JSON? Что в случае первого у вас все данные поднимаются одним запросом (поскольку, фактически, представляют из себя набор key-value) и это запрос достаточно прост, а в случае второго вы вообще не паритесь, и, фактически, передаёте на клиента BLOB (поскольку его внутренняя структура вам совершенно не интересна)?
Приведенный график не даёт ответа на вопрос, в какой же момент времени дизайн системы начинает окупаться
Собственно это — самый главный вывод. Как писали, если не ошибаюсь, Том с Тимом: «Все говорят что им нужно качество. Угадайте от чего отказываются в первую очередь?»
Есть мнение что проблемы с БД не в том, что традиционные БД работают недостаточно быстро. То есть, конечно, специализированные системы управления данными превосходят по производительности системы общего назначения (это не только баз данных касается), вот только область применения специализированных решений «немного» поуже. И быстродействие — характеристика, безусловно, важная, но далеко не единственная.
Я к тому, что это задним числом понятно что «нужно было, просто врезаться в лоб и сохранить корабль». А к трагедии, как обычно, привёл не один какой-то косяк, а серия, в целом не очень вероятных, причин. И переборки, и шлюпки и много чего ещё.
Поспорили терапевт с ветеринаром у кого работа сложнее. Спорили-спорили, не могут договориться. Ветеринар предлагает:
— Давай тестовый приём проведём?
— Давай!
— Ну вот представь, я пришёл к тебе на приём. Что бы будешь делать?
— На что жалуетесь?
— Э, нет! Так каждый дурак может!
Но квалифицированных специалистов (что в IT, что HR, что в управлении) — мало. Поэтому, в большинстве случаев, никто не следует разумным советам из статьи.
Это не совсем так. Точнее совсем не так. Просто оно будет записано не в виде ограничения (CONSTRAINT), а в виде схемы данных, где сумма фигурирует один раз и к ней так или иначе «подвязаны» два счёта. Такой, классический «транзакционный» (не в смысле СУБД, а в смысле бухгалтерского учёта) вариант. Правда при такой схеме остаток (сальдо) по счёту не хранится, а требует вычисления каждый раз, когда он потребуется.
Это вообще не цель и не задача. Это ограничение. Ну или поясните как именно вы собираетесь измерять «степень соответствия регламенту при выполнении работы»
Это не цель и даже не задача (потому что в нём ничего не говорится о том для чего и/или как это должно быть выполнено). Это требование (нефункциональное).
Это тоже требования (см. выше). Если уклон будет 2%% это лучше чем если он будет 12%%? В какую сторону должны быть направлены усилия тех, кто будет этот уклон формировать?
Это вообще не несёт никакой смысловой нагрузки.
Это более-менее похоже на цель, но она категорически не SMART (в том числе в части М — если столбцов будет внесено не один, а семь можно ли сказать что результаты превзошли ожидания?)
Опять мимо. Здесь вообще ничего измерить нельзя!
Под конец вам (или автору статьи) почти удалось. Почти, потому что не указано 80% от чего. От производительности на начало квартала? От максимальной производительности по итогам прошлого года? От проектной производительности?
В общем, судя по всему, все статьи про SMART которые вы видели были, мягко говоря, не очень… Так что погуглить, в данной ситуации, лучше вам!
Цели — это «Что?» и «Для чего?», а задачи — это «Как?» Единственный смысл задачи без цели — потратить ресурсы.
Никак не буду. С точки зрения БД они все одинаковые (потому что семантика существует только на стороне того кода, который на основании этих данных будет рендерить формы)
Ну, если у вас несколько сотен тысяч форм…
Хотя 100 млн. это, вообще говоря, не много. В чём проблема поднять по индексам десяток значений атрибутов одного объекта (по его ключу) — вам виднее. По мне 6 секунд на 100 млн. записей (для значений, да и для объектов даже) — это не долго. Это ОЧЕНЬ долго.
По вашим пунктам:
1. Если у вас формы с, максимум дюжиной элементов — да. По мне такие формы, скорее, исключение.
2. Можно да, а можно нет. А в данным случае вы будете это делать обязательно.
3. Никакой рефакторинг в данной ситуации вам не поможет. Максимум чего вы добьётесь — это регулярной уборки. Если вам нравится сначала раскидывать мусор, а потом регулярно его убирать — кто вам может запретить? Но на мой взгляд это довольно странная стратегия
4. Любой лог — это просто инструмент. Вы забываете про то, что он не сделает счастья автоматически. Но, повторюсь, если вам нравится всё время приводить в порядок разбегающийся зоопарк — это ваше законное право. В каждой избушке свои погремушки.
5. О разработчиках, которые будут эти поля заполнять и использовать
6. см. ответ на ответ 3. Помноженный на то, что вы в одном месте храните совершенно разные данные (в них нет никакой логической связи «по-вертикали»).
Что вы хотите услышать про EAV и JSON? Что в случае первого у вас все данные поднимаются одним запросом (поскольку, фактически, представляют из себя набор key-value) и это запрос достаточно прост, а в случае второго вы вообще не паритесь, и, фактически, передаёте на клиента BLOB (поскольку его внутренняя структура вам совершенно не интересна)?
Собственно это — самый главный вывод. Как писали, если не ошибаюсь, Том с Тимом: «Все говорят что им нужно качество. Угадайте от чего отказываются в первую очередь?»