1

次の 2 つのデータベース レイアウトのどちらかを選択する際に、いくつかの洞察を実際に使用できます。

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

中小企業、個人事業主向けの課金アプリです。最初のレイアウトには請求書用の個別のテーブルがなく、代わりに請求サイクル番号の DETAILS のフィールド「期間」に依存しています。2 番目のレイアウトでは、請求書専用のテーブルが導入されています。

具体的には、このアプリケーションでは、どの時点でレイアウト #1 が壊れていることがわかりますか? データの量が増えるにつれて、どのようなことが難しくなりますか? レイアウト #2 の場合、追加された柔軟性/複雑さは、実際には何を意味しますか? 30-60-90 歳の老化にはどのような影響がありますか? いつか必ず必要になると思います。

より一般的には、これは、テーブルのフィールドまたはまったく新しいテーブルを介して何かを追跡/制御するかどうかの一般的なケースのようですが、実際には正規化の問題ではありませんか? 一般的にどのように選択しますか？

4

3 に答える 3

2

以前のコメントを考えると、これは私がそれにアプローチする方法です：

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

===========

上記では、「ケース」を開き、それを顧客に関連付けます。継続的に、1 人以上の人が請求書をケースに適用します。

請求開始日と請求期間の組み合わせが経過すると、システムは請求テーブルから詳細をコピーした新しい請求書を作成します。これは、まだ請求されていない詳細に基づいて行う必要があります。請求書が発行されたら、将来の変更から請求レコードをロックする必要があります。

別のトリガーが必要な場合は、「BillPeriod」を他のタイプのフィールドに変更する必要がある場合があります。たとえば、期間は、請求書を作成するための「トリガー」の 1 つにすぎません。

特定の金額に達したときに請求書を送信することが含まれる場合があります。これは、顧客レベルまたはケース レベルで構成できます。別のオプションは、支出の上限です。たとえば、ケース レベルでキャップ値を設定すると、請求額が上限を超えるのを防ぐことができます。または、少なくとも関係者にアラートが送信されるようにします。

于 2011-06-13T16:17:36.597 に答える
2

注文自体ではなく、商品に「期間」が付けられている理由がよくわかりません。レイアウト #1 は、何年にもわたって追加および支払いが行われる可能性のある「詳細」で構成されるオープンな「注文」を持つことができることを暗示しているようです。これは非常に間違っているようで、会計を悪夢にするはずです。レイアウト #2 は実際にはあまり良くありません。

一般的に言えば、注文は購入日または契約日を持つ単一のトランザクションで構成されます。そのトランザクションには複数の詳細項目が含まれる場合がありますが、それでも 1 つのトランザクションです。これは、買い手と売り手の間で特定の時点で行われた単一の契約を表します。新しいアイテムが購入されると、新しい注文が作成されます...これを念頭に置いて、どちらのテーブル構造も機能しません。

請求書について。注文には、1 つ以上の請求書が添付されている場合があります。請求書の目的は、請求書に対して支払いを適用することです。小規模なトランザクションの場合、請求書と注文の間に 1 対 1 の関係があります。

大規模なトランザクションでは、1 つの注文に複数の請求書が適用される場合があります。たとえば、「199.99 ドルの 3 回の簡単な支払い ...」を行う契約を結んでいる場合。この場合、$199.99 の 3 つの請求書がそれぞれ $599.97 の合計である 1 つの注文に適用されます。そして、それぞれ異なる時期に期限がきます。

Invoice テーブルには、少なくとも注文 ID、請求書番号、請求日、請求額、期日、取引 ID (クレジット カードの場合)、小切手番号 (明白)、金額、および受領日フィールドが必要です。

現実の世界をより詳しくサポートしたい場合は、請求書番号、受領額 (または返金額)、受領日、トランザクション ID、および小切手番号を格納する Payments テーブルを追加で作成します。この方法を使用する場合は、請求書テーブルからこれらのフィールドを削除してください。

ここで、定期的な請求 (インターネット ホスティングなど) をサポートする必要がある場合は、"Contracts" および "ContractDetails" などと呼ばれる別のテーブルが必要になります。これらのテーブルには、契約の詳細が格納されます (注文および注文の詳細に似ていますが、開始日、終了日、繰り返し期間が含まれます)。次の請求期間になると、詳細を使用して注文が作成され、適切な請求書が生成されます。

于 2011-06-09T22:27:31.830 に答える
1

法的な請求を行っているので、SageTimeslipsの機能を確認することをお勧めします。弁護士は他の人のように振る舞いません。弁護士向けの会計ソフトウェアは、他の会計ソフトウェアのようには動作しません。それはビジネスの性質です。

30日間の無料トライアルがあり、ヘルプファイルとドキュメントから多くのことを学ぶことができます。

さらに、ユーザーインターフェイスからのデータベース設計のリバースエンジニアリングは良い習慣です。

于 2011-06-15T03:08:00.323 に答える