Использовать поле или совершенно новую таблицу?

Question

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

Layout #1          | Layout #2  
                   |  
CUSTOMERS          | CUSTOMERS  
 id int pk         |  id int pk  
 info char         |  info char  
                   |  
ORDERS             | ORDERS  
 id int pk         |  id int pk  
 customerid int fk |  customerid int fk  
 date timedate     |  date timedate  
                   |  
DETAILS            | INVOICES  
 id int pk         |  id int pk  
 orderid int fk    |  orderid int fk  
 date timedate     |  date timedate  
 description char  |  
 amount real       | DETAILS  
 period int        |  id int pk  
                   |  invoiceid int fk  
                   |  date timedate  
                   |  description char  
                   |  amount real  

Это приложение для выставления счетов для малого бизнеса, индивидуальный предприниматель. В первом макете нет отдельной таблицы для счетов-фактур, а вместо этого используется поле 'period' в DETAILS для номера цикла выставления счета. Второй макет представляет таблицу специально для счетов-фактур.

В частности, в этом приложении, в какой момент вы видите, что Layout # 1 ломается, или какие вещи будут становиться все сложнее и сложнее с увеличением объема данных? Что касается компоновки № 2, что означает дополнительная гибкость / сложность в практическом плане? Каковы последствия для 30-60-90 старения? Я уверен, что это будет необходимо в какой-то момент.

В более общем плане, это, кажется, общий случай того, отслеживаете ли вы что-либо через поле в таблице или в новой таблице, но это не проблема нормализации, не так ли? Как вы вообще делаете выбор?

Answer 1

Учитывая предыдущие комментарии, я подхожу к этому так:

CUSTOMERS
  id int pk
  info char

CASES
  id int pk
  customerid int fk
  dateOpened datetime
  dateClosed datetime
  status int <- open, closed, final billed, etc.
  BillPeriod int <- here is where you determine how often to bill the client.
  BillStartDate datetime <- date that billings should start on.

BILLING
  billingid int pk
  caseid int fk
  userid int fk <- id of person who is charging to this case. i.e. the lawyer.
  invoicedetailid fk <- nullable, this will make it easier to determine if this particular item has been invoiced or not.
  amount money
  billdate datetime
  billingcode int fk <- associate with some type of billing code table so you know what this is: time, materials, etc.
  description char


INVOICES
  invoiceid int pk
  customerid int FK
  invoicedate datetime
  amount money <- sum of all invoice details
  status int <- paid, unpaid, collection, etc..
  discount money <- sum of all invoice details discounts
  invoicetotal <- usually amount - discount.

INVOICEDETAILS
  invoicedetailid int PK
  invoiceid int FK
  billingid int FK
  discount money <- amount of a discount, if any

===========

В приведенном выше случае вы открываете "дело""и связать это с клиентом.На постоянной основе один или несколько человек применяют Биллингс к делу.

По истечении комбинации даты и срока начала счета-фактуры система создаст новый Счет-фактуру с подробностями, скопированными из таблицы фактур.Это следует делать исходя из тех деталей, которые еще не были выставлены.Вы должны заблокировать учетную запись от будущих изменений, как только она будет выставлена ​​в счет.

Возможно, вам придется изменить «BillPeriod» на поле другого типа, если вам нужны другие триггеры.Например, точка - это всего лишь один «триггер» для создания счета.

Можно включить отправку счета, когда вы наберете определенную сумму в долларах.Это может быть настроено на уровне клиента или случая.Другой вариант - ограничение расходов.Например, установление предельного значения на уровне случая, которое не позволит счетам превышать предельное значение;или, по крайней мере, вызывает отправку оповещения соответствующим сторонам.

Answer 2

Я не совсем уверен, почему к товару прикреплен «период» вместо самого заказа.План № 1, кажется, подразумевает, что вы можете иметь открытый «заказ», который состоит из «деталей», которые могут быть добавлены и оплачены в течение нескольких лет.Это кажется очень неправильным и должно сделать бухгалтерский учет кошмаром.План № 2 на самом деле не намного лучше.

Вообще говоря, Заказ состоит из одной транзакции с датой покупки или контракта.Эта транзакция может включать несколько деталей, но все же это одна транзакция.Он представляет собой единое соглашение, заключенное в определенный момент времени между покупателем и продавцом.Если новые предметы приобретаются, создается новый заказ ... С учетом этого ни одна из таблиц не работает.

В отношении счетов-фактур.К заказу может быть прикреплен один или несколько счетов.Целью счетов-фактур является применение к ним платежей.Для небольших транзакций существует связь один к одному между счетами и заказами.

В более крупных транзакциях может быть несколько счетов, которые применяются к одному заказу.Например, если вы заключили договор на «3 простых платежа по 199,99 $ ...».В этом случае у вас будет 3 счета на 199,99 долларов США, каждый из которых будет применен к одному заказу на общую сумму 599,97 долларов США;и каждый срок платежа в разные периоды времени.

В таблице счетов должно быть как минимум идентификатор заказа, номер счета, дата счета, сумма счета, дата оплаты, идентификатор транзакции (для кредитной карты), номер чека (очевидно)), Поля «Полученная сумма» и «Дата получения».

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

---

Теперь, если вам нужно поддерживать повторяющиеся платежи (например, хостинг в Интернете), тогда у вас будет другая таблица под названием «Контракты»."и" ContractDetails "или что-то подобное.В этих таблицах будут храниться данные контракта (аналогично заказам и деталям заказа, но с указанием даты начала, даты окончания и повторяющегося периода).При достижении следующего расчетного периода данные будут использоваться для создания заказа и создания соответствующих счетов-фактур.

Answer 3

Поскольку вы занимаетесь законным выставлением счетов, я бы посоветовал вам потратить некоторое время на изучение возможностей Sage Timeslips .Адвокаты не ведут себя как другие люди;бухгалтерское программное обеспечение для адвокатов не ведет себя так же, как другое бухгалтерское программное обеспечение.Это характер бизнеса.

У них есть 30-дневная бесплатная пробная версия, и вы, вероятно, сможете многому научиться из файлов справки и документации.

Кроме того, обратный инжиниринг проектирования баз данных изпользовательский интерфейс - хорошая практика.