Question

我的任务是使用SQL Server向现有Web应用程序添加一些功能。

我的客户的业务提供的服务是向员工发放密钥，然后员工前往各个地点执行所请求的工作。她想跟踪谁拥有客户的钥匙。他们有大约100-125个客户和6名员工。她将是唯一一个使用网络gui签发和归还钥匙的人。

为了获得灵感，我去了谷歌并找到了一个名为KEY ORGANIZER的演示程序，该程序在桌面上运行。它完全符合我的客户所需，但它是一个桌面应用程序，而不是一个Web应用程序。所以，我想我只是对它进行逆向工程，并根据客户的需求进行定制。桌面应用程序比我的客户端需要更多。以下是她正在寻找的内容的高级概述：

发行密钥：

她点击了客户姓名旁边的关键图像。假设她有3个客户钥匙，但所有3个钥匙已经检查给员工。她会收到一些警告，说明没有可用的密钥可以发布，但仍然允许她在库存关闭的情况下发出密钥（因此数据库需要能够处理负值）。如果有可用密钥，则继续下一个项目符号。
在下一个窗口中，她会看到一个表单。（可供选择的员工名单和今天的日期）。
她从下拉列表中选择员工，然后单击“确定”按钮，关闭模态窗口。
每次退房/登记时都会输入一个日志条目，每次办理登机手续和退房手续时都会向员工发送一封电子邮件。

返回密钥：

她还希望能够选择客户名称旁边的按钮，以查看哪些员工当前拥有密钥，并能够选择员工姓名以返回密钥。
同样，我的客户希望点击员工的姓名来查看他们所拥有的密钥列表是否能够从列表中返回密钥。
每次退房/登记时都会输入一个日志条目，每次办理登机手续和退房手续时都会向员工发送一封电子邮件。

我不需要帮助编写网页。我只需要一些关于如何正确设置数据库表的指导（例如，如果密钥库存字段是现有表的一部分或者例如是不同的表），以便最好地处理循环密钥库存场景。

以下是我提出的表格：

Customer_tbl （现有表格）
    •客户ID
    •KeyQTY（新字段？）
    •KeyLabel（新字段？）

Employee_tbl （现有表格）
    •员工ID
    •Fn
    •Ln

KeyJournal_tbl （新表）
    •JournalID
    •ActionDate
    •ActionPerformedID（密钥问题，密钥返回，密钥丢失等）
    •客户ID
    •员工ID
    •库存（从客户收到的密钥总数 - 或者应该在Customer_tbl下？）     •IssueReturnDate

KeyInventory_tbl （新表）
    •KeyID
    •客户ID
    •KeyTotal

注意：我添加了SQL Server 2005标记仅供参考。如果标记具有误导性，我不需要SQL语句的帮助。

Answer 1

我的倾向与你的关系非常接近。这里：

Customer
  customer_id
  name, address, etc, whatever reference info you need

Employee
  employee_id
  name, etc

KeyInventory
  key_id
  description
  customer_id
  qty

KeyCheckout
  employee_id
  key_id
  checkout_date
  return_date

注意：

我对KeyInventory进行了描述，因为我假设您可以为客户提供多个密钥，并且需要区分它们，例如“Apt 1”和“Apt 2”，或“Warehouse”和“Office”

当员工获得密钥时，请创建一个KeyCheckout记录，其中包含给出的日期。返回密钥后，请填写退货日期。如果返回日期为空，则密钥仍然没有。

要查找哪些员工拥有客户密钥@cx：

选择employee_id 来自KeyCheckout c 在i.key_id = c.key_id上加入KeyInventory i 其中i.customer_id = @cx 和c.return_date为空

要查找有多少关键@kx仍可用：

选择i.qty - count（c.employee_id）来自KeyInventory i 在c.key_id = i.key_id上加入KeyCheckout c并且c.return_date不为空其中i.key_id = @kx

等

你肯定想要一个关于return_date的索引，或者KeyCheckout（key_id，return_date）和KeyCheckout（employee_id，return_date），因为这个表会变得非常大而没有索引查询会慢得无法忍受。

我认为您的Journal表与我的Checkout类似。我只是将结帐和返回字段放在一条记录中，以便更容易确定密钥是否仍然存在。对于输入和输出的单独记录，你必须匹配它们，这是一种痛苦。

不要将数据放入日记类型记录中。这不是“交易”的属性，它是关键本身的属性。它属于库存表。

不要将密钥数量放在客户记录中。如果您需要知道客户有多少不同的密钥，只需从keyinventory中选择count（*），其中customer_id = @cx。将此计数存储在客户记录中只会产生与实际密钥记录数不匹配的可能性。

我不确定“关键标签”是什么。如果这是密钥的描述，它属于KeyInventory记录，因为客户可能有多个密钥。我认为说客户只能拥有一把钥匙是不合理的。即使今天对您的客户来说恰好如此，未来客户似乎也可能拥有多个密钥，但也可能允许它。

我认为你的库存是非序列化的，即同一个锁的3个键没有彼此区分，它只是“数量3”，对吧？如果他们有单独的序列号，那么就没有数量字段，并且每个键都有单独的记录。

主管经理数据库设计

1 个答案: