Что назвать столбец в таблице базы данных, которая содержит номер версии

Question

Я пытаюсь выяснить, как назвать столбец в моей таблице базы данных, который содержит INT для конкретной «версии записи». В настоящее время я использую " RecordOrder ", но мне это не нравится, потому что люди думают, что выше = новее, но то, как я это использую, ниже = новее (при этом "1" является текущим запись, «2» является вторым по популярности, «3» старше, и так далее). Я рассмотрел " RecordVersion ", но я боюсь, что будет та же проблема. Любые другие предложения? " RecordAge "

Я делаю это, потому что, когда я вставляю в таблицу, вместо того, чтобы выяснить, какая версия будет следующей, а затем риску быть украденным у меня, прежде чем писать, это число, я просто вставляю вставку с "RecordOrder "of 0. В таблице AFTER INSERT есть триггер, который увеличивает все числа" RecordOrder "для этого ключа на 1, поэтому только что вставленная мной запись становится" 1 ", а все остальные увеличиваются на 1. Таким образом, вы можете получить текущую запись человека, выбрав RecordOrder = 1 вместо получения MAX (RecordOrder) и затем выбрав его.

PS - Я также открыт для критики по поводу того, почему это ужасная идея, и я должен вместо этого увеличивать этот индекс. Казалось, что это значительно облегчило поиск, но если это плохая идея, пожалуйста, просветите меня!

Некоторые подробности о данных, например:

У меня есть следующая таблица базы данных:

CREATE TABLE AmountDue (
    CustomerNumber INT,
    AmountDue      DECIMAL(14,2),
    RecordOrder    SMALLINT,
    RecordCreated  DATETIME
)

Подмножество моих данных выглядит так:

CustomerNumber    Amountdue      RecordOrder                 RecordCreated
           100            0                1       2009-12-19 05:10:10.123
           100        10.05                2       2009-12-15 06:12:10.123
           100       100.00                3       2009-12-14 14:19:10.123
           101         5.00                1       2009-11-14 05:16:10.123

В этом примере для клиента 100 есть три строки - они должны 100 долларов, затем 10,05 долларов, и теперь они ничего не должны. Дайте мне знать, если мне нужно уточнить это еще.

UPDATE:

Столбцы «RecordOrder» и «RecordCreated» недоступны для пользователя - они предназначены только для внутреннего использования и помогают выяснить, какая запись является текущей записью клиента. Кроме того, я мог бы использовать его для возврата надлежащим образом упорядоченной истории клиентов, хотя я мог бы так же легко сделать это с датой. Полагаю, что я могу выполнить то же самое, что и увеличивать «версию записи» только с датой RecordCreated, но это исключает удобство знания, что RecordOrder = 1 является текущей записью, и я вернулся к выполнению подзапроса с MAX или MIN в DateTime для определения самой последней записи.

Answer 1

Я думаю, что "current version = 1" - плохая идея, потому что, когда вы добавляете новую текущую запись, вам придется обновить ВСЕ предыдущие версии.И любые другие таблицы или приложения, которые ссылаются на старые номера версий, теперь будут неправильными.Мне нужно написать сервис, который взаимодействует с программой для мэйнфреймов, которая работает подобным образом, и это была огромная головная боль, которая потратила десятки часов на разработку.увеличивается каждый раз.Затем, когда я хочу найти самую новую запись, я order by version_id desc в запросе и выбираю только первую строку.

Редактировать: Я не увидел тег datawarehousing, на который только что указал iandismeиз.Если выбор всех версий не сработает, я видел некоторые системы, в которых есть отдельная таблица, в которой просто хранится самая последняя версия для каждой записи в другой таблице.Поэтому, когда новая версия добавляется в таблицу Record, соответствующая запись RecordVersion обновляется для сохранения этой новой версии.Это всегда было излишним для вещей, над которыми я работаю, но я не работаю над целыми хранилищами данных, поэтому я не знаю, будет ли это лучше или хуже.

Answer 2

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

Таким образом, независимо от того, кто и в какое время добавляет строку, не будет никакой двусмысленности относительно последней версии строки.

Я думаю, что перенумерация всех связанных строк в id + 1 не очень хорошая идея по нескольким причинам:

1. Вы меняете то, что не нужно менять
   • Блокировка и блокировка увеличатся
   • Использование большей вычислительной мощности и памяти, чем требуется

Answer 3

Мне нравится идея Радж Мора использовать метку времени. Но я понимаю, что любой запрос, ищущий последние записи, будет трудным и вызовет тяжелую обработку.
Поэтому я хотел бы предложить эту идею: использовать метку времени (она есть в любом случае) для порядка записи, но оставьте одно байтовое поле, чтобы легко идентифицировать последнюю запись.
В этом случае текущая запись будет иметь значение LatestRecord = 1, а каждая другая = NULL. Таким образом, вы можете создать индекс, игнорирующий нули?
Это значительно упростит все ваши запросы.

Answer 4

Есть ли причина, по которой вы не можете использовать дату RecordCreated, чтобы выполнить по существу то же самое?

Делать что-то вроде:

select top 1 columna, columnb, etc. from table order by RecordCreated desc

даст вам новейшую запись, и вам не придется беспокоиться об изменениях записи.

Вы могли бы потенциально вызвать всевозможные проблемы с подходом перенумерации записей (конфликт по индексам, повышение блокировки и т. Д.).

Блокировка эскалации: http://msdn.microsoft.com/en-us/library/aa213033(SQL.80).aspx

Указатель конкуренции: http://blogs.digineer.com/blogs/jasons/archive/2009/02/25/monitoring-index-contention-with-dmfs.aspx

Как уже упоминали другие в отношении хранилищ данных, вы всегда можете поместить представление или снимок или что-то подобное поверх набора данных, чтобы предоставить вам данные в желаемом формате (только самая новая запись и т. Д.). Очевидно, я не знаю, какие ваши ограничения или требования достаточно, чтобы знать, просматривать ли / снимок / и т.д. имеет смысл в вашей ситуации.

Answer 5

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

Почему бы просто не использовать поле идентификатора, и тогда нумерация будет автоматической (тогда не будет проблемы с кражей номера перед вставкой). Действительно ли имеет значение, повторяется ли нумерация для каждого клиента, если вы можете заказать по идентификатору desc и номеру клиента, чтобы просмотреть все записи для одного человека? Или вы можете использовать поле даты записи, возможно, чтобы упорядочить записи.

Answer 6

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

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

Идеязапуск триггера для изменения большого количества записей при вставке одной из них - плохая идея, поскольку с добавлением записей это становится все более и более дорогим.

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

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