Лучшая стратегия для хранения адресов заказов

Question

У меня есть вопрос «стратегии».

Дело в том, что у нас есть таблица адресов и заказов клиентов.Структура выглядит примерно так (просто пример, игнорируйте типы полей и т. Д.):

Address
id INT
line1 TEXT
line2 TEXT
state TEXT
zip TEXT
countryid INT

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

Orders
id INT
productid INT
quantity INT
delivery_address TEXT

delivery address - это что-то похожее на CONCAT_WS("\n",line1,line2,state,zip,country_name)

Все хорошо и модно, однако кажется, что клиентам нужен доступ к историческим данным и возможность их экспортироватьв формате XML, и они хотят снова правильно разделить эти строки.Поскольку иногда нет строки 2, состояния, zip или чего-либо еще, как мы можем хранить эту информацию таким образом, чтобы мы могли затем расшифровать «метку» каждой строки?

Было предложено сохранение в виде закодированного массива JSON, ноэто лучший способ?Я думал о том, чтобы сохранить его в формате XML ... или, может быть, создать эти 6-10 дополнительных столбцов и хранить адресные данные при каждом заказе?Возможно, некоторые из вас, ребята, имеют больше опыта работы с подобными вещами и смогут указать мне правильное направление.

Заранее спасибо!

Answer 1

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

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

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

см. Запись в Википедии для медленно меняющихся размеров

Answer 2

Лучший способ IMHO - добавить историю в адресную таблицу.Это приведет к добавлению дополнительных элементов для его ключа (скажем, address_id и {start_of_validity, end_of_validity}) Идентификатор клиента, который становится внешним ключом в таблице клиентов.Таблица заказов ссылается только на поле address_id (которое «стабильно» во времени).Новые заказы будут ссылаться на «текущую» строку в адресе.

Примечание: я не знаю json.

Answer 3

когда вы говорите «ранее это было сделано по ссылке, но это неправильно, потому что, если адрес меняет все старые заказы, также меняется адрес доставки, что неверно», это не было так неправильно ...

Забавно, не правда ли?

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

Answer 4

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

Любой другой подход (конкатенация, JSON, XML) заставит вас выполнять анализ, когда вам нужен доступ к информации.

Answer 5

Чтобы иметь возможность использовать адресные данные для будущего использования, вам определенно необходимо сохранить как можно больше метаданных (то есть таких полей, как адрес, город, штат и почтовый индекс).Потеря этих данных путем объединения их в одну строку выглядит проще и может сэкономить небольшое количество места, но в конце концов это не лучший метод.На самом деле, разбить его на части очень сложно - очень похоже на отделение имени и фамилии от общего столбца с именем «один размер для всех».Хранение данных в полных записях, использование 6-10 новых полей (как уже упоминалось) - лучший путь.

Еще лучше было бы стандартизировать адреса (по крайней мере, адреса США) при их первом вводе.,Это будет гарантировать, что адрес является реальным и доставляемым и устранит проблемы с доставкой в ​​будущем.Мои мысли всегда сохраняют как можно больше данных, потому что хранение дешевое, а данные ценны.

В интересах полного раскрытия информации я являюсь учредителем SmartyStreets .Мы предоставляем проверку адреса улицы.