Дизайн БД для счетов за коммунальные услуги

Question

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

Сегодня каждый счет за коммунальные услуги имеет несколько разных сообщений/строк. Например electricity законопроект может включать fixed fee (сумму за DATERANGE законопроекта) consumption (обычно выставлен счет за кВтч электроэнергии, м3 для воды и т.д.) taxes (может быть энергетические налоги)

Как я хочу, чтобы иметь возможность использовать базу данных позже, чтобы искать данные для разных периодов времени, типы счетов счетов и т. д. Мне нужно придумать прочный дизайн db. Итак, нижеследующее будет моим началом.

`utility_bill` 
    `id` int(11) 
    `vendor_id` int(11) 
    `type_id` int(11) 
    `notes` varchar(255) 
    `date_issued` date 
    `date_due` date 

`utility_bill_rows` 
    `id` int(11) 
    `utility_bill_id` int(11) 
    `name` varchar(64) 
    `startdate` date 
    `enddate` date 
    `units` double 
    `unit_price` double 
    `unity_type` varchar(16) 

Пример данных:

`utility_bill` 
1 2 2 Electricty bill (august) 2016-09-01 2016-09-30 

`utility_bill_rows` 
1 1 Fixed fee 2016-08-01 2016-08-31 31 10 days 
2 1 Consumption 2016-08-01 2016-08-31 500 1 kwh 
3 1 Government taxes 2016-08-01 2016-08-31 500 0.1 kwh 

В приведенном выше примере bill_total будет 310 + 500 + 50 = 860

Не все коммунальные платежи основаны на ежемесячных циклов. В некоторых случаях это может быть 2016-07-01 to 2016-09-30, 2016-08-15 to 2016-09-15 и так далее. Поэтому я думал о добавлении нового столбца в таблицу utility_bill_rows под названием daily_cost, которая была бы просто (units * unit_price)/(enddate - startdate in days).

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

Answer 1

Некоторые предложения:

Предположим, что вы хотите, чтобы в общей сложности все налоги, взимаемые в течение определенного времени. У вас будет `where name =" Правительственные налоги "в запросе. Это не очень здорово и просто неудобно.

Попробуйте поставить эти категории в отдельной таблице поиска по имени, о, billedUnits:

ID Name  Other_info 
1 Fixed fee ... 
2 Consumption ... 
3 Taxes  ... -- "Government" is a duplicative redundancy 

Затем, вместо поля name в utility_bill_rows, используйте billedUnitID и использовать значение идентификатора таблицы перекодировки. Это также облегчает добавление новых категорий, таких как «Солнечная доплата».

Наиболее значительным преимуществом было бы добавить поле term в таблице utility_bill. Это может быть односимвольный обозначение типа «М» для ежемесячного и «Q» для квартала или небольшого целого числа, такого как 30 и 90 для дней срока. Это значительно упростит запросы, касающиеся только ежемесячных счетов или только квартальных счетов. Я немного склоняюсь к целому числу, так как это упростит расчет за день.

Вы можете добавить поле daily_cost, если содержимое строки стабильно - то есть, если вы когда-то записывали значения, которые редко меняются. Если есть относительно частые корректировки, не беспокойтесь, просто пересчитайте, когда это необходимо.

Также имейте в виду понятия «стоимость» и «заряд». В конце концов, все эти значения являются обвинением. Ваш клиент видит расходы. Поэтому, если вы создадите это поле, лучшим именем будет daily_charge.