Идеи для управления запасами с использованием MySQL

Question

Я создаю базу данных для издательской компании. Компания имеет около 1300 книг и около 6-7 офисов. Теперь я создал таблицу, которая отображает товар на складе во всех местах. Таблица должна выглядеть следующим образом для пользователя :

Book Name          Location1            Location2          Location3 ......
History              20000               3000               4354
Computers             4000               688                344
Maths                 3046               300                0
...

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

Column1- Book_ID   Column2- Location_ID     Column3- Quantity
     1                  1                        20000
     1                  2                        3000
     1                  3                        4354
     2                  1                        4000
     2                  2                        688
   ...

Итак, я думаю, что это не лучший способ хранения данных, так как в итоге получится 1300 (Books) X 7 (Locations) = 9100 rows. Есть ли лучший способ хранения данных. Теперь у меня может быть 7 дополнительных столбцов в стабильной Книге, но если я создам новое местоположение, мне нужно будет добавить еще один столбец в таблицу Книг.

Буду признателен за любой совет, или если вы считаете, что вышеуказанный метод подходит или нет.

Answer 1

Нет, это лучший способ сделать это.

То, что у вас есть, это отношения «многие ко многим» между книгами и местоположениями. Это почти в всех случаях хранится в базе данных как "ассоциативная" таблица между двумя основными объектами. В вашем случае у вас также есть дополнительная информация об этой ассоциации, а именно, это «запас» или «количество» (или, если вы думаете об этом как о графике, величина соединения, или ребро вес).

Итак, может показаться , что у вас много "дублирования", но на самом деле это не так. Если бы вы попытались сделать это любым другим способом, это было бы на намного менее гибким. Например, при имеющемся у вас дизайне не требуется любое изменение схемы базы данных, чтобы добавить еще тысячу разных книг или еще 20 местоположений.

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

Answer 2

Это наиболее распространенное (и эффективное) решение. Большинство фреймворков, таких как Django, Modx и несколько других, реализуют отношения Many2Many только через промежуточную таблицу, используя отношения внешнего ключа.

Убедитесь, что вы правильно проиндексировали свою таблицу.

ALTER TABLE stock_management add index (Book_ID), add index (Location_ID)

Answer 3

Это действительно лучший способ сделать это; у вас есть 9100 независимых данных для хранения, поэтому вам действительно нужно 9100 строк (на самом деле меньше; строки, в которых количество равно 0, могут быть опущены.) Другой способ размещения данных потребовал бы изменения структуры таблицы при изменении местоположения. был добавлен.