То что трепались это заметно ...


Если бы была дискуссия, но вы ее уводите в болтологию и кидание какашками, а это мне не интересно.


Одну и ту же задачу в программировании можно решить разными способами и зачастую приоритет различных способов не очевиден, поэтому абсолютистское мнение, что какой то способ должен быть единственным имеющим право на существование, является именно субъективным мнением.


К чему этот абсурдный пример? Вы считаете, что 2+2=5? Ну да переубеждать вас не имеет смысла, поэтому и общение с вами было прекращено.


А я говорю, что вы не правы и мне тоже как-то все равно, останетесь вы при своём мнении, или нет, и у меня тоже нет цели вас в чем-то убедить.


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


И какой ответ вы хотите на этот высер? Можете не отвечать ...

PS: общение с вами дорогой мой неадекватный друг закончено.

Увы, все что вы описали в своем пространном посте вы начали первым, собственно и получаете в ответ.

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

Чтобы было еще больше конкретики, таблица t - 70 миллионов записей, таблица t_log - 700 миллионов записей.
запрос из t - (select * from t where some_date between d1 and d2), где d1 и d2 - параметры. В случае с таблицей t_log необходимо по максимальной дате some_date попадающей в интервал d1-d2 найти идентификаторы и по ним отобрать записи из таблицы t.

Продемонстрируйте свою компетенцию, докажите ваше утверждение.

hVostt,
Мусорный фон в ваших сообщениях мне не интересен, поэтому смотреть и отвечать буду только по конкретике.


Т.е. вместо добавления поля в основную таблицу, вы предлагаете создать таблицу расширения 1:1 и получить дополнительное соединение в запросах и что самое главное, дополнительные затраты на поддержку этого расширения, и этот костыль вы предлагаете в контексте OLTP систем, я правильно понял?


Т.е. если вы захотите например иметь время изменения ключевых статусов объекта, пусть их будет 5 и отбирать объекты по этому времени, то вы вместо добавления 10 полей (статус, дата) создадите дополнительные 5 табличек (1:1) с двумя полями и во всех запросах по всему приложению добавите 5 соединений с этими дополнительными табличками, также будете поддерживать триггеры вставляющие и изменяющие записи в эти 5 табличек?

Вы педалируете эту тему (что является ничем иным как переход на личности и начали хамить именно вы и продолжаете это делать, за что получаете в ответ) уже много сообщений подряд и вот наконец то я увидел конкретику, и оказалось, что такие говнокостыли которые вы предлагаете я уже делал и делал их когда в основную таблицу добавлять поля по тем или иным причинам было запрещено. Т.е. ваш подход для меня совсем не нов и в разрезе oltp это лютый трэш, для oltp это равносильно 2*2=5. Если вы это делаете в аналитической системе, то это совершенно другой вопрос, но в oltp это антипаттерн.

Вкратце минусы такого подхода: на операции DML на основной таблице мы вынуждены делать дополнительные операции по поддержке таблиц расширений; на таблицах расширений должен быть как минимум один индекс на id, т.е. 20 таблиц расширений, двадцать индексов, что очень "положительно" сказывается на производительности вставки записей; когда мы получаем данные, мы вынуждены присоединять таблицы расширений, что очень "положительно" сказывается на производительности запросов, если понадобился составной индекс из полей основной таблицы и поля из дополнения ... ; поиск по полям принадлежащим нескольким таким таблицам тоже очень "положительно" сказывается на производительности запросов. И имея такую кучу минусов утверждать, что это решение для oltp систем лучше чем добавление полей необходимых для оперативной работы в основную таблицу, это за гранью логики.


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


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

1. Совершенно верно, таблица лога не должна использоваться для оперативной работы о чем я и говорил, но вы почему то с этим спорили, почему вы с этим спорили? Поменяли свое мнение?
2. Таблица логов решает свою задачу и она вполне себе нормализованная, дублирования данных в ней нет.
3. Таблица логов нужна для разбора полетов, если что то пошло не так. Естественно данные в таблице факта достоверны и актуальны, даже если кто то внес ошибочные данные, они являются фактом и именно на тот случай что кто то внес недостоверную информацию нужна таблица логов, чтобы посмотреть что кто и когда и принять решение о том как откорректировать факт.
4. 70 миллионов в факте, допустим каждый объект в среднем проходит 10 состояний, итого получаем 700 в логе, это вполне реальное соотношение и такой прирост за 5 лет это даже не сильно нагруженная система, а лог за прошлые годы можно банально заархивировать куда нибудь в сторонку и удалить из оперативной системы, разумеется если на нем кто то нехороший не построил логику оперативной работы. Факт -> лог дорога с односторонним движением, т.е. никаких цепочек она не порождает и никакую базу не положит.
6. Что касается запросов данных для максимальной даты попадающей в интервал то вот 13931438 и вот 8947782 как они выглядят. Но когда таблица лога начинает использоваться подобным образом для работы оперативной системы, это ведет к сильной просадке производительности, у нее другое предназначение и ходят за данными в нее обычно при проведении исследования кто и как нагадил, ходят по конкретному идентификатору объекта, т.е. в логи при нормальном раскладе обычно идут с конкретным идентификатором, а таких записей в нашем примере 70/700 там всего 10 штук.

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

"и тут вообще стоит запретить какие-либо изменения-удаления записей" - запрет изменения вы себе как представляете?

У вас логика проявляет все признаки отсутствия присутствия, вы не понимаете суть oltp систем в принципе, на сим не вижу смысла пытаться вам объяснять что дважды два четыре, это бесполезно в вашем случае и тратить на вас время бессмысленно, тем более что конкретики снова никакой, одни общие слова.

Количество индексов не влияет на вставку записей? ну ну ...
Транзакционные данные асинхронно? Ну ну ...
Влияния на нормализованную модель данных нет? Я веду с вами беседу в контексте oltp систем, если нет влияния на оперативную работу и оперативные данные, то это рядом стоящая аналитическая система и каким боком это относится к контексту oltp?

Я вам про oltp, а вы мне говорите что прекрасно делаете срезы, витрины, проекции, процедуры загрузки в них (ETL), вот только при чем тут oltp?


И вам того же, топайте проектируйте дальше, горе-проектировщик

Это не левый чувак, это Добрый Э - Эх , а вот вы действительно левый чувак))

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

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

Почему же вы тогда с пеной у рта спорили и утверждали обратное?))

Да и посмотрел на ваш запрос, он неправильный ... )) что же вы так, товарищ hVostt за вас вписался, а вы запросы писать не умеете)), все таки посмотрите ссылочки на то как правильно писать такие запросы))