Каков лучший метод/опции для истекающих записей в базе данных?

butterknife 10.x поддерживает только сборки с поддержкой AndroidX. Вы перейдете на версию 9.0.0

. Из плагина gradle gradle 3.0 apt устарела, удалите classpath 'com.neenbedankt.gradle.plugins:android-apt:1.8'

библиотеку build.gradle

apply plugin: 'com.android.library'
apply plugin: 'me.tatarka.retrolambda'
apply plugin: 'com.jakewharton.butterknife'

buildscript {
    repositories {
        google()
        jcenter()
        mavenCentral()
    }
    dependencies {
        classpath 'me.tatarka:gradle-retrolambda:3.2.3'
        classpath 'com.jakewharton:butterknife-gradle-plugin:9.0.0'
    }
}
5
задан BartoszKP 22 January 2014 в 23:26
поделиться

9 ответов

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

3
ответ дан 14 December 2019 в 04:48
поделиться

Мне нравится expired_flag опция по date_expired опции, если скорость запроса важна для Вас.

2
ответ дан 14 December 2019 в 04:48
поделиться

Я думаю, добавляя date_expired столбец является самым легким и наименее агрессивным методом. Пока Ваши ВСТАВКИ и ВЫБИРАЕТ использование явные списки столбцов (они должны быть то, если они не), затем нет никакого влияния на Ваши существующие операции CRUD. Включите индекс date_expired столбец и разработчики могут добавить его как свойство к любым классам или логике, которые зависят от данных в существующей таблице. В целом, оптимальное значение для усилия. Я соглашаюсь, что другие методы (т.е. архивные таблицы) неприятны для сравнения.

1
ответ дан 14 December 2019 в 04:48
поделиться

Мне обычно не нравятся триггеры базы данных, так как они могут привести к странному "негласно", поведение, но ставить триггер удаляет для вставки about-to-be-deleted данных в таблицу истории, могла бы быть опция.

По моему опыту, мы обычно просто используем "Активный" бит или дату и время "DateExpired" как Вы упомянутый. Это работает вполне прилично и действительно легко иметь дело с и запрос.

Существует связанное сообщение здесь, которое предлагает несколько других опций. Возможно, опция CDC?

Таблица истории SQL Server - заполняет через SP или Триггер?

1
ответ дан 14 December 2019 в 04:48
поделиться

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

Некоторые возможные перечисляемые значения для использования, в зависимости от потребностей:

  1. Активный
  2. Удаленный
  3. Приостановленный
  4. InUse (Вид механизма псевдоблокировки)

Настройте столбец как tinyint (это - SQL Server... не уверенный в эквивалентном MySQL). Можно также установить справочную таблицу соответствия с парами ключ/значение и ограничением внешнего ключа между таблицами, если Вы желаете.

1
ответ дан 14 December 2019 в 04:48
поделиться

Я всегда использовал ValidFrom, ValidTo приблизьтесь, где каждая таблица имеет эти два дополнительных поля. Если ValidTo Is Null or > Now() затем Вы знаете, что у Вас есть допустимая запись. Таким образом можно также добавить данные к таблице, прежде чем это будет живо.

1
ответ дан 14 December 2019 в 04:48
поделиться

Очень хороший подход Oracle к этой проблеме является разделами. Я не думаю, что MySQL имеет что-то подобное все же.

-1
ответ дан 14 December 2019 в 04:48
поделиться

Существуют некоторые поля, которые обычно имеют мои таблицы: creation_date, last_modification, last_modifier (fk пользователю), is_active (булевская переменная или число, в зависимости от базы данных).

0
ответ дан 14 December 2019 в 04:48
поделиться

Посмотрите на "Медленно Изменяющийся Размер" алгоритмы SCD. Существует несколько вариантов от мира Организации хранилищ данных, которые применяются здесь.

Ни один не является "лучшим" - каждый отвечает на различные требования.

Вот опрятная сводка.

Тип 1: новая запись заменяет исходную запись. Никакая трассировка старой записи не существует.

  • Тип 4 является вариацией на это, перемещает историю в другую таблицу.

Тип 2: новая запись добавляется в клиентскую таблицу измерений. Различать, "допустимый диапазон дат" пара столбцов в необходимом. Это помогает иметь "эту запись, текущий" флаг.

Тип 3: исходная запись изменяется для отражения изменения.

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

Можно читать больше об этом при поиске "Медленно Изменяющегося Размера".

http://en.wikipedia.org/wiki/Slowly_Changing_Dimension

0
ответ дан 14 December 2019 в 04:48
поделиться
Другие вопросы по тегам:

Похожие вопросы: