Хранение деталей позиции заказа клиента, куда идти? - PullRequest
Новая
       4

Хранение деталей позиции заказа клиента, куда идти?

0 голосов
/ 06 сентября 2011

Я работаю над типом приложения для управления запасами, используя следующую смесь или технологии: MySql, C #, WPF, ADO.Net EntityFramework 4.

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

Вот как у меня это было раньше ... Я сохранил детали в поле LongText в виде строки XML. 

+---------------------------------------------------+
| SalesInvoices                                     |
+---------------------------------------------------+
| int InvoiceID: primary key, auto-incretement      |
| int OrderID                                       |
| int CustomerID                                    |
| int CreatedByEmployeeID                           |
| DateTime Date                                     |
| DateTime? ShippingDate                            |
| LongText ItemsData (details, stored as XML)       |
| LongText TransactionData (details, stored as XML) |
| Double Subtotal                                   |
| Double Tax                                        |
| Double Freight                                    |
| Double FreightTax                                 |
| Double Total                                      |
+---------------------------------------------------+

Однако я посмотрел в Интернете, и большинство примеров, которые я видел, имеют отдельную таблицу SalesInvoiceDetails. Так что мне интересно, есть ли что-то не так с моим подходом, если я пойду через проблему перехода на подход.

Мои требования: Поиск в таблице SalesInvoice должен быть очень быстрым. Мне не нужно искать в деталях счета, если пользователь фактически не открывает счет, так что все в порядке, если пользователь должен подождать секунду или две здесь.

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

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

1 Ответ

0 голосов
/ 06 сентября 2011

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

Также я нашел хорошую статью здесь . Мне действительно понравилось то, что написал автор (хорошая идея отказаться от вашего подхода):

Это не плохой подход, поскольку он регистрирует каждую покупку, сделанную каждым клиентом. Но что, если вы начали задавать сложные вопросы, такие как:

Сколько 3 "красных экранов заказали Freens R Us в 2002 году?

Каковы общие продажи 56 "Blue Freens в штате Техас?

Какие товары были проданы 14 июля 2003 года?

Это моё мнение :) 1027 *

...