使用字段还是整个新表？

| 在以下两种数据库布局之间进行选择时，我真的可以使用一些见解。 
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中的字段'period \'作为开票周期号。第二种布局引入了专门用于发票的表格。 特别是在此应用程序中，您会在什么时候看到Layout＃1中断，或者随着数据量的增加，什么样的事情会越来越难？就布局2而言，增加的灵活性/复杂性实际上意味着什么？ 30-60-90老化有何影响？我确定在某些时候这是必要的。 更一般而言，这似乎是您是通过表中的字段还是整个新表来跟踪/控制某些内容的一般情况，但这并不是一个正常的问题，不是吗？您通常如何选择？     
2020-01-29 4 条评论
分享

没有找到相关结果

    已邀请:

    末钉蹈泰唬

            鉴于之前的评论，这就是我的处理方式： 
    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
    =========== 在上面，您打开一个\“ case \”并将其与客户关联。不断有一个或多个人将Billings应用于该案件。 帐单开始日期和期间组合起来后，系统将创建一个新的发票，其中包含从“帐单”表中复制的“明细”。它应基于尚未开票的那些详细信息进行此操作。开票后，您应该锁定帐单记录以防止将来的更改。 如果需要不同的触发器，则可能必须将“ BillPeriod \”更改为其他类型的字段。例如，期间只是创建发票的一个“触发器”。 其中可能包括当您达到一定金额时发送发票。可以在客户或案例级别进行配置。另一种选择是限制支出。例如，将封顶值设置为案例级别，这将防止帐单超出封顶；或至少导致将警报发送给相关各方。     
    2020-01-29 0 0
    分享

    链眷克袒姜

            我不完全确定为什么将\“句点\”附加到商品而不是订单本身。布局＃1似乎暗示您可以拥有一个由“明细”组成的未结“订单”，该“明细”可能会在几年内添加并支付。这似乎是非常错误的，应该使会计成为噩梦。布局2确实并没有好多少。 一般而言，订单由具有购买或合同日期的单笔交易组成。该交易可能包含多个明细项目，但仍是一项交易。它代表买卖双方在特定时间达成的单一协议。如果购买了新物品，则会创建一个新订单...考虑到这一点，这两个表结构都不起作用。 关于发票。订单可能附有一张或多张发票。发票的目的是对它们应用付款。对于小额交易，发票和订单之间存在一对一的关系。 在较大的交易中，您可能有多个应用于单个订单的发票。例如，如果您已约定支付\“ 3笔轻松付款$ 199.99 ... \”。在这种情况下，您将有3张发票，每张订单的价格为$ 199.99，总金额为$ 599.97；并且每个到期时间不同。 然后，发票表应至少具有订单ID，发票编号，发票日期，发票金额，到期日期，交易ID（对于信用卡），支票编号（明显），已收金额和已收日期字段。 如果您想花大价钱并支持更多真实世界，那么您将另外拥有一个“付款”表，该表存储了发票编号，已收（或退款）金额，已收日期，交易ID和支票号码。如果您使用此路线，请从“发票”表中删除这些字段。 现在，如果您需要支持经常性收费（例如，互联网托管），那么您将拥有一个名为\“ Contracts \”和\“ ContractDetails \”或类似名称的表。这些表将存储合同详细信息（类似于订单和订单详细信息，但包括日期开始，日期结束和重复周期）。当下一个结算期到来时，该详细信息将用于创建订单并生成适当的发票。     
    2020-01-29 0 0
    分享

    版萍层分

    由于您要进行法律结算，因此建议您花一些时间查看Sage Timeslips的功能。律师的行为不像其他人。律师的会计软件的行为与其他会计软件不同。这是业务的本质。 他们有30天的免费试用期，您可能可以从帮助文件和文档中学到很多东西。 此外，从用户界面对数据库进行逆向工程是一种好习惯。     
    2020-01-29 0 0
    分享
    为什么被折叠? 0 个回复被折叠

    要回复问题请先登录或注册

    或代码 OrCode.com 备案号：粤ICP备15020848号-1
    Escape time: 0.05135703086853