Встраивание тарифа на склад в таблицы MySQL

Question

Создание правильной структуры базы данных с помощью ручного тарифа

Мне поручено довольно сложное проектирование базы данных, и я подумал, что кто-то может дать мне несколько советов, которые помогут начать работу.В настоящее время у нас есть система складирования и складирования товаров, и теперь мы хотели бы использовать эти данные для расчета затрат на хранение.
База данных уже содержит следующее: дата поступления товара, дата выхода товара, вес партии, количество штук,Габариты, описание товара, тип контейнера для хранения (если применимо).Данные хранятся в MySQL, что может не подходить для структуры тарифов ниже.

Вот структура начисления для диапазона 1,2,3,4.У нас есть около 12 групп в зависимости от размера и важности клиента.Все остальные полосы являются производными от следующих:

ГРУППА 1 По прибытии на наш объект € 0,04 за килограмм + € 4,00 за груз для генеральных грузов € 0,07 за килограмм для ЖУРНАЛОВ - НИКАКОГО ХРАНЕНИЯ ЗАРЯДКА ХРАНЕНИЕ ЗАРЯДКИ ПОСЛЕ 5 ДНЕЙ€ 4,00 за неповрежденный поддон, максимальный размер 120x100x160 см (Стандартный деревянный поддон со склада) € 6.50 за кубический метр на сыпучих или негабаритных грузах.ГРУЗ ПОСТАВЛЯЕТСЯ В СПЕЦИФИЧЕСКИХ КОНТЕЙНЕРАХ 20 ПОДДОНОВ 20 футов - € 50,00 ТОЛЬКО ПОДДОН 40 футов - € 20,00

ГРУППА 2 0,04 за килограмм без минимальной зарядки.ТОЛЬКО - € 20,00

ГРУППА 3 € 0,03 за килограмм + € 3,00 за груз до 2000 кг € 0,02 за килограмм + € 2,00 за груз свыше 2000 кг Сбор за хранение ПОСЛЕ 5 ДНЕЙ € 4,00 за поддон макс. Размер 120x100x160 € 0,04 за грузкилограмм сыпучих грузов

ГРУППА 4 € 5,00 за поддон ЗАРЯДКИ НА ХРАНЕНИЕ ПОСЛЕ 4 ДНЕЙ € 5,00 за поддон максимальный размер 120x100x160

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

Кто-нибудь имел опыт работы с подобным руководством по преобразованию системы?

Answer 1

Вероятно, алгоритм вычисления тарифа слишком сложен для использования в SQL. Итак, давайте подойдем к вашему вопросу с другой точки зрения.

1. Создайте алгоритм на своем клиентском языке (Java / PHP / VB /...).
2. Когда вы делаете шаг 1, подумайте, какие данные нужны - возможно, массив из двух столбцов «days» и «Euros»? Может быть, что-то с участием "килограмм"? Может быть, есть несколько моделей - дни и / или килограмм?
3. Создайте таблицу или таблицы, необходимые для хранения этих массивов.
4. Решите, как указать, что килограммы не имеют значения - возможно, пропустив какие-либо строки в таблице килограммов? Или дополнительный столбец, который дает размер / вес?

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

Вот другой подход. Вместо того, чтобы иметь столбцы для дней, килограммов и т. Д., Просто используйте строку JSON с любыми необходимыми факторами. В клиентском коде декодируйте JSON, а затем используйте подходящие операторы IF для работы с килограммами, если они есть, ELSE ... и т. Д.

Опять же, база данных - это просто постоянное хранилище; клиент управляет форматом тем, что ему удобно.

В любой реализации будет столбец для типа элемента, а также Band. SELECT будет иметь ORDER BY Band. Обратите внимание, что не было бы понятия 12; может быть реализовано любое число .

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