Разработка БД для коммунальных платежей

Question

Разработка БД для коммунальных платежей

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

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

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

`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),

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

2

mysql database-design

Источник

user3419021 30 сен '16 в 09:54

1 ответ

Другие вопросы по тегам mysql database-design

user3658753 30 сен '16 в 18:15 2016-09-30 18:15 · Answer 1 · 2016-09-30 18:15

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

Предположим, вы хотите суммировать все налоги, взимаемые за определенное время. В запросе у вас будет `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 Таблица. Это может быть односимвольное обозначение, например, "M" для месячных и "Q" для ежеквартальных, или маленькое целое число, например, 30 и 90 для дней срока. Это значительно упростит запросы, которые касаются только ежемесячных счетов или только квартальных счетов. Я немного склоняюсь к целому числу, поскольку это также упростит расчет за день.

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

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