Как я могу обрабатывать несколько строк в одной таблице?

Question

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

В настоящее время данные хранятся в таблице котировок, который выглядит следующим образом:

QuoteID (PK, AutoNumber) data1, data2, data3 и так далее.

Внешние ключи QuoteID для других таблиц для одного-многих отношений для получения подробной информации о цитате.

Есть ли способ сохранить все изменения в таблице котировок И обрабатывать ревизии? Таким образом, отношения FK с другими таблицами не будут нарушены.

Answer 1

Основываясь на том, что вы сказали, и каких-то gueses относительно того, что еще/что вам нужно, я придумал схему структуры таблицы (таблицы в ALLCAPS, столбцы в CamelCase, столбцы, заканчивающиеся на Id, являются идентификаторами или подходящими натуральными ключами , где имя ColumnId соответствует этому имени таблицы, это первичный ключ, в противном случае это внешний ключ в родительской таблице): записи

-- CUSTOMER ---- 
CustomerId 

-- QUOTE ---- 
QuoteId 
CustomerId 
Data1Id 

-- QUOTEREVISION ---- 
QuoteRevisionid 
QuoteId 
CreatedAt 
Data2Id 
Data3Id 

-- DATA1 ---- 
Data1Id 

-- DATA2 ---- 
Data2Id 

-- DATA3 ---- 
Data3Id 

клиент, который может сделать котировки.

QUOTE отслеживает ценовые котировки клиентов. Одна строка для каждого заданного [независимо], для которого они вводят кавычки.

QUOTEREVISION записывает каждую ревизию котировки, в которую они входят. Когда сначала создается котировка, будет создано первое QuoteRevision. CreatedAt был бы датированным, чтобы отслеживать, когда они произошли. QuoteId + CreatedAt - это естественный ключ для таблицы, поэтому вам может не понадобиться QuoteRevisionsId.

DATA1, DATA2, DATA3 и другие при необходимости содержат дополнительную информацию. Я сконфигурировал Data1 для хранения информации, относящейся к уровню котировки, т. Е. Тот же факт применим к каждой ревизии котировок. Data2 и Data3 будут содержать данные, которые могут варьироваться от пересмотра до пересмотра.

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

Answer 2

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

Answer 3

Я согласен с дизайном Филиппа Келли, я могу только заметить, что ревизия цитаты, которую вы можете рассчитать на выходе, используя ROW_NUMBER() или эмуляцию в соответствии с вашей СУБД.

Существует также хорошая книга о хранении исторических данных: http://www.cs.arizona.edu/people/rts/tdbbook.pdf

Answer 4

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

-- DATA1 ---- Data1Id

-- DATA2 ---- Data2Id

-- DATA3 ---- Data3Id

Что вы думаете о создании этих элементов данных в качестве столбцов в таблице изменений вместо этого?