Интересно, как вы это делаете и сколько времени уходит.
У меня обычно несколько итераций содержит взаимосвязанные рефакторинги и добавления фич (переименовал метод, сделал новый класс, выделил в базовом классе метод так что это задело новый класс для фичи и так далее). Мне отделение рефакторинга от нового кода представляется сложным.
В предметной области, как мне кажется, наоборот возможно несовпадение реального количества и количества по документам. Это совпадение желательно, но возможно что оно и не соблюдается (и этот факт фиксируюется инветаризационной описью). Так что это наше решение разрешать ли хранение расхождения или нет.
Предположим у нас бумажный учет, и на складе разбилась люстра. От момента события до момента учета события может быть какой-то промежуток и может наблюдаться различие. Документы показывают одно а в реальности другое.
PS. И в определениях нормализации вообще не сказано, что откуда пришло, так что это не важно в данном контексте
Думаю, продукт коллектива из журналистов и переводчиков производит несколько искаженное впечатление относительно целей создания фичи.
В исходнике что цель выяснить насколько люди знают и юзают фичи софта, чтобы предложить им тренинг (если мало кто употребляют @ надо рассказать об этой фиче):
Productivity Score identifies areas where you can offer people training to learn how to use the tools to their fullest capacity. For example, the new teamwork category (available today) provides a score based on the percentage of people who engage in teamwork within shared workspaces like SharePoint, Microsoft Teams, and group mailboxes in Exchange.
…
We get it, and we are committed to privacy as a fundamental element of Productivity Score. Let me be clear: Productivity Score is not a work monitoring tool. Productivity Score is about discovering new ways of working, providing your people with great collaboration and technology experiences. It focuses on actionable insights about the ways in which people and teams are using the tools so you can make improvements or provide training to further your digital transformation.
Ок, переформулирую. "Мы не считаем, что в реальности абстракция "Товары" и абcтракция "Документы" это одно и то же.
Что такое "абстракция в реальности"? Абстракция есть в голове у кого-то (в какой-то модели).
В бухгалтерии есть еще понятие "двойная запись", там тоже одна величина должна соответствовать другой. Моделирование ее в базе вы тоже считаете денормализацией?
Прочтите определение понятия "денормализация" и примените каждый признак, пожалуйста, его к вашему примеру. Для удобства я их пронумерую циферками.
Денормализация (англ. denormalization) — (1) намеренное(2)приведение структуры базы данных в состояние, (3)не соответствующее критериям нормализации, обычно проводимое с целью ускорения операций чтения из базы за счет добавления избыточных данных.
Я видел как структуры данных, в которых форма соблюдена (Проводка это, счет дебета, счет кредита, сумма) как и структуры данных в которых таковая есть.
"номер транзакции, счет, дебет/кредит, сумма". Во втором случае требовался дополнительный шаг по валидации того, что транзакция сбалансирована, но зато получение остатков было проще писать, например.
Приведите мне пожалуйста определение нормальной формы, в котором есть слова "избыточные данные" и "самостоятельная сущность".
Соответствие документов и товаров идет из предметной области, а не является результатом такого проектирования БД.
Является. Можно спроектировать БД так, чтобы сознательно нарушать это соответствие. Например, у нас eventual consistency или просто мы так решили потомучто. Мы можем игнорировать это соотвествие в каких-то целях. Мы решаем какое подмножество правил модели предметной области реализовывать в нашем БД.
Ну я обычно смотрю в словарь, если не знаю значения слов.
Денормализация (англ. denormalization) — намеренное приведение структуры базы данных в состояние, не соответствующее критериям нормализации, обычно проводимое с целью ускорения операций чтения из базы за счет добавления избыточных данных.
А где тут технические детали, я вижу только логические детали разного уровня абстракции. Тут нет ничего про процессоры, винты, которыми прикручивают SSD и так далее.
Вопрос в том, как вы будете это моделировать.
Так НФ это и есть про модели. Какие ограничения вы хотите ввести в вашей модели реальности.
В реальности нет никаких товаров и документов, есть только (грубо говоря) атомы. Документы, товары, остатки на складе это абстракция.
hpmor
Хорошо. Выкинем этот мусор девятнадцатого века.
Реальность — это не атомы, не множество маленьких бильярдных шаров, летающих вокруг. Маленькие шарики — это просто ещё одна ложь. Представление об атомах как о маленьких точках — лишь ещё одна общепринятая галлюцинация, за которую цепляются люди, потому что они не хотят сталкиваться с нечеловечески чуждой формой скрывающейся за ней реальности. Неудивительно, что его попытки трансфигурации, основанные на таком представлении, не работали. Если он хочет власти, он должен отбросить человеческую природу и заставить мысли соответствовать математическим формулировкам квантовой механики.
Нет никаких частиц, есть лишь облака амплитуд в пространстве состояний множества частиц. И то, что его мозг наивно считает ластиком, не более чем гигантский множитель волновой функции, который тоже можно разложить на множители. Сказать, что он самостоятельно существует, всё равно, что сказать — внутри числа «шесть» существует независимый множитель «три». И если палочка Гарри способна изменять множители в волновых функциях, которые можно хотя бы приблизительно на множители разложить, значит, чёрт побери, она может изменить немного меньший множитель, который мозг Гарри видит как участок ластика…
Из той абстракции, которая существует в голове у специалиста, мы выделяем подмножество, которое нам удобно реализовать в виде программы. В этом подмножестве мы вводим свои правила. Мы можем учитывать товары как нам удобно. Можем один единичный товар записывать записью, если нас это интересует. Можем учитывать партиями, если нам не нужен единичный товар. Можем учитывать просто общее количество без учета партий.
Поверх этого мы вводим свои правила целостности и, наконец, решаем как компьютер будет считать нашу модель.
Если мы решаем, с учетом всего перечисленного, что БД не должна позволять вводить остатки, которых нет ни в каком документе, то у нас есть ограничение. Если мы считаем, что можно вводить данные непосредственно в таблицу остатков и расхождение это нормально, то у нас нет ограничения.
Дальше мы применяем определения из книжек нашим табличкам и можем узнать, находятся они в какой-то НФ или нет.
Дальше мы можем узнать, какие последствия этого нас ожидают и принять решение о том, надо ли нам нормализовывать|денормализовывать или нет.
Не важно является ли это dоmain или еще каким-то ограничением. Если оно должно соблюдаться, значит это не соответствует этой НФ.
Например, если в таблицу остатков можно ввести от балды данные, и это нормально в рамках принятых вами в процессе дизайна решений, то нарушение НФ нет, так как в базе допустимо расхождение.
Если нельзя (например, если МОЛ могут ввести в нее данные только посредством документа "инвентаризационная опись") то тогда есть нарушение этой НФ.
Логически ведь ничем не отличается, мы только агрегацию убрали.
Что такое "логически не отличается"? И куда убрали агрегацию? Количество товара осталось зависимым документов, просто присутствие записи это 1 а отсутствие это 0.
Для того, чтобы ответить на вопрос "является ли X Y" надо:
Найти определение, что такое X (в данном случае структура БД приведена в статье)
Найти определение, что такое Y (в данном случае "денормализованный" — возможно подвергнувшийся денормализации)
Попробовать применить Y к X чтобы, узнать подходит ли определение к ситуации. В данном случае, мы узнаем, что денормализация — уход от НФ для каких, то целей. Это нас отсылает к списку НФ, перебираем НФ по списку доходим до ДКНФ — на русском статья куцая так что переходим в английский раздел. И там читаем:
Domain-key normal form (DK/NF) is a normal form used in database normalization which requires that the database contains no constraints other than domain constraints and key constraints.
Если не знаем что такое "ограничение" ищем определение для этого.
Теперь задаем вопрос, есть ли у нас ограничения кроме доменных и ключевых? Да, для того, чтобы корректно обновить таблицу current_stocks сумма там должна соответствовать таблице documents.
Следовательно схема БД не соответствует ДКНФ.
Хотелось бы, чтоб прежде чем беспокоить окружающих подобными вопросами их авторы предпринимали хотя бы небольшие самостоятельные усилия по поиску информации.
Определения можно так же прочитать в книге "Введения в системы баз данных" К. Дж. Дейт.
Поиск виновного может минимизировать риск другого ограбления. Так же он может помочь скомпенсировать последствия ограбления.
Тут тонкость в том, что такое "Возложить ответственность" если речь идет о чувстве вины или типа того, то это одно. Если о внешнем действии "Подать в суд" — это другое.
Поэтому жертва не виновата, но часто несет какую-то ответственность.
Это все хорошо, до тех пор пока вы не поддерживаете обратную совместимость, вот там уже нефинал, надо максимально аккуратно и вообще не использовать.
Если вы ставите финал, то вы не даете другим расширять класс
Если вы не ставите финал, то вы либо занимаетесь поддержкой обратной совместимости для точки расширения, которую, возможно, никто не использует либо ломаете обратную совместимость.
Интересно, как вы это делаете и сколько времени уходит.
У меня обычно несколько итераций содержит взаимосвязанные рефакторинги и добавления фич (переименовал метод, сделал новый класс, выделил в базовом классе метод так что это задело новый класс для фичи и так далее). Мне отделение рефакторинга от нового кода представляется сложным.
В предметной области, как мне кажется, наоборот возможно несовпадение реального количества и количества по документам. Это совпадение желательно, но возможно что оно и не соблюдается (и этот факт фиксируюется инветаризационной описью). Так что это наше решение разрешать ли хранение расхождения или нет.
Предположим у нас бумажный учет, и на складе разбилась люстра. От момента события до момента учета события может быть какой-то промежуток и может наблюдаться различие. Документы показывают одно а в реальности другое.
PS. И в определениях нормализации вообще не сказано, что откуда пришло, так что это не важно в данном контексте
Думаю, продукт коллектива из журналистов и переводчиков производит несколько искаженное впечатление относительно целей создания фичи.
В исходнике что цель выяснить насколько люди знают и юзают фичи софта, чтобы предложить им тренинг (если мало кто употребляют @ надо рассказать об этой фиче):
Итак, самостоятельная сущность это синоним избыточные данные. Отлично. Будем дальше так использовать.
Если мы его решили не делать, то да, а если мы его решили делать, то становится. Это мы ж в процессе проектирования решили его моделировать да?
Что такое "абстракция в реальности"? Абстракция есть в голове у кого-то (в какой-то модели).
Прочтите определение понятия "денормализация" и примените каждый признак, пожалуйста, его к вашему примеру. Для удобства я их пронумерую циферками.
Денормализация (англ. denormalization) —
(1) намеренное (2)приведение структуры базы данных в состояние, (3)не соответствующее критериям нормализации, обычно проводимое с целью ускорения операций чтения из базы за счет добавления избыточных данных.
Я видел как структуры данных, в которых форма соблюдена (Проводка это, счет дебета, счет кредита, сумма) как и структуры данных в которых таковая есть.
"номер транзакции, счет, дебет/кредит, сумма". Во втором случае требовался дополнительный шаг по валидации того, что транзакция сбалансирована, но зато получение остатков было проще писать, например.
Приведите мне пожалуйста определение нормальной формы, в котором есть слова "избыточные данные" и "самостоятельная сущность".
Является. Можно спроектировать БД так, чтобы сознательно нарушать это соответствие. Например, у нас eventual consistency или просто мы так решили потомучто. Мы можем игнорировать это соотвествие в каких-то целях. Мы решаем какое подмножество правил модели предметной области реализовывать в нашем БД.
Ну я обычно смотрю в словарь, если не знаю значения слов.
Денормализация (англ. denormalization) — намеренное приведение структуры базы данных в состояние, не соответствующее критериям нормализации, обычно проводимое с целью ускорения операций чтения из базы за счет добавления избыточных данных.
А где тут технические детали, я вижу только логические детали разного уровня абстракции. Тут нет ничего про процессоры, винты, которыми прикручивают SSD и так далее.
Так НФ это и есть про модели. Какие ограничения вы хотите ввести в вашей модели реальности.
В реальности нет никаких товаров и документов, есть только (грубо говоря) атомы. Документы, товары, остатки на складе это абстракция.
Хорошо. Выкинем этот мусор девятнадцатого века.
Реальность — это не атомы, не множество маленьких бильярдных шаров, летающих вокруг. Маленькие шарики — это просто ещё одна ложь. Представление об атомах как о маленьких точках — лишь ещё одна общепринятая галлюцинация, за которую цепляются люди, потому что они не хотят сталкиваться с нечеловечески чуждой формой скрывающейся за ней реальности. Неудивительно, что его попытки трансфигурации, основанные на таком представлении, не работали. Если он хочет власти, он должен отбросить человеческую природу и заставить мысли соответствовать математическим формулировкам квантовой механики.
Нет никаких частиц, есть лишь облака амплитуд в пространстве состояний множества частиц. И то, что его мозг наивно считает ластиком, не более чем гигантский множитель волновой функции, который тоже можно разложить на множители. Сказать, что он самостоятельно существует, всё равно, что сказать — внутри числа «шесть» существует независимый множитель «три». И если палочка Гарри способна изменять множители в волновых функциях, которые можно хотя бы приблизительно на множители разложить, значит, чёрт побери, она может изменить немного меньший множитель, который мозг Гарри видит как участок ластика…
Из той абстракции, которая существует в голове у специалиста, мы выделяем подмножество, которое нам удобно реализовать в виде программы. В этом подмножестве мы вводим свои правила. Мы можем учитывать товары как нам удобно. Можем один единичный товар записывать записью, если нас это интересует. Можем учитывать партиями, если нам не нужен единичный товар. Можем учитывать просто общее количество без учета партий.
Поверх этого мы вводим свои правила целостности и, наконец, решаем как компьютер будет считать нашу модель.
Если мы решаем, с учетом всего перечисленного, что БД не должна позволять вводить остатки, которых нет ни в каком документе, то у нас есть ограничение. Если мы считаем, что можно вводить данные непосредственно в таблицу остатков и расхождение это нормально, то у нас нет ограничения.
Дальше мы применяем определения из книжек нашим табличкам и можем узнать, находятся они в какой-то НФ или нет.
Дальше мы можем узнать, какие последствия этого нас ожидают и принять решение о том, надо ли нам нормализовывать|денормализовывать или нет.
Не важно является ли это dоmain или еще каким-то ограничением. Если оно должно соблюдаться, значит это не соответствует этой НФ.
Например, если в таблицу остатков можно ввести от балды данные, и это нормально в рамках принятых вами в процессе дизайна решений, то нарушение НФ нет, так как в базе допустимо расхождение.
Если нельзя (например, если МОЛ могут ввести в нее данные только посредством документа "инвентаризационная опись") то тогда есть нарушение этой НФ.
Для этого надо определить что значит "являться денормализацией другой"
Что такое "логически не отличается"? И куда убрали агрегацию? Количество товара осталось зависимым документов, просто присутствие записи это 1 а отсутствие это 0.
Я подробнее написал в этом комментарии
Для того, чтобы ответить на вопрос "является ли X Y" надо:
Если не знаем что такое "ограничение" ищем определение для этого.
Теперь задаем вопрос, есть ли у нас ограничения кроме доменных и ключевых? Да, для того, чтобы корректно обновить таблицу current_stocks сумма там должна соответствовать таблице documents.
Следовательно схема БД не соответствует ДКНФ.
Хотелось бы, чтоб прежде чем беспокоить окружающих подобными вопросами их авторы предпринимали хотя бы небольшие самостоятельные усилия по поиску информации.
Определения можно так же прочитать в книге "Введения в системы баз данных" К. Дж. Дейт.
Я думаю, есть нарушение ДКНФ -> она не нормализована
Имхо знающий мотивированный джун, даже без коммерческого опыта который имеет представление об институтской теории весьма ценен.
Не интересующийся специальностью джун который погулял пары по алгоритмам и проектированию БД нафиг не нужен
Для компаний этот вопрос можно сформулировать так "Надо ли посылать нафиг разрабов которым мы не готовы компенсировать релокейт?".
Потому, что если запрещать определенные условия сделок, получается что и разрабы получат меньше возможностей.
Вот можешь ты переехать без компенсации, а фиг — Фил запретил.
Потому, что разрабы недостаточно взрослые, чтобы самим нести ответственность за то, на что сами договорились?
Поиск виновного может минимизировать риск другого ограбления. Так же он может помочь скомпенсировать последствия ограбления.
Тут тонкость в том, что такое "Возложить ответственность" если речь идет о чувстве вины или типа того, то это одно. Если о внешнем действии "Подать в суд" — это другое.
Поэтому жертва не виновата, но часто несет какую-то ответственность.
Это никак не меняет суть противоречия, просто вводит дополнительную индикацию в номере версии
Если человек лезет куда-то через рефлексию это само по себе большой красный флаг, что его использование не соблюдает контракт.
Конечно лучше. Чем никто. А если кто-то может то может и не лучше?
Это все хорошо, до тех пор пока вы не поддерживаете обратную совместимость, вот там уже нефинал, надо максимально аккуратно и вообще не использовать.
Если вы ставите финал, то вы не даете другим расширять класс
Если вы не ставите финал, то вы либо занимаетесь поддержкой обратной совместимости для точки расширения, которую, возможно, никто не использует либо ломаете обратную совместимость.