0

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

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

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

颁发密钥：

  1. 她单击客户姓名旁边的关键图像。假设她有 3 把客户钥匙，但所有 3 把钥匙都已签出给员工。她会收到某种警报，说明没有可发出的密钥，但在库存关闭的情况下仍允许她发出密钥（因此数据库需要能够处理负值）。如果有可用的密钥，则继续执行下一个项目符号。

  2. 在下一个窗口中，她会看到一个表格。（可供选择的员工姓名列表和今天的日期）。

  3. 她从下拉列表中选择员工并单击“确定”按钮，然后模式窗口关闭。

  4. 每次签出/签入都会输入一个日志条目，并且在每次签入和签出时都会向员工发送一封电子邮件。

钥匙归还：

  1. 她还希望能够选择客户姓名旁边的按钮以查看哪些员工当前拥有密钥，并能够选择员工姓名以返回密钥。

  2. 同样，我的客户希望单击员工的姓名以查看他们是否拥有密钥列表，并能够从列表中返回密钥。

  3. 每次签出/签入都会输入一个日志条目，并且在每次签入和签出时都会向员工发送一封电子邮件。

我不需要网页编码方面的帮助。我只需要一些关于如何正确设置数据库表的指导（例如，关键库存字段是否应该是现有表或不同表的一部分）以最好地处理循环密钥库存方案。

这是我想出的表格：

Customer_tbl（现有表）
• CustomerID
• KeyQTY（新字段？）
• KeyLabel（新字段？）

Employee_tbl（现有表）
• EmployeeID
• Fn
• Ln

KeyJournal_tbl（新表）
• JournalID
• ActionDate
• ActionPerformedID（密钥问题、密钥返回、密钥丢失等）
• CustomerID
• EmployeeID
• Inventory（从客户收到的密钥总数——或者应该在 Customer_tbl 下？）
• IssueReturnDate

KeyInventory_tbl（新表）
• KeyID
• CustomerID
• KeyTotal

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

4

1 回答 1

0

我的倾向与你的很接近。这里：

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 的密钥：

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

要查找仍有多少密钥 @kx 可用：

从 KeyInventory 中选择 i.qty - count(c.employee_id) 我在 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 where customer_id=@cx 中选择 count(*)。将此计数存储在客户记录中只会产生与关键记录的实际数量不匹配的可能性。

我不确定“keylabel”是什么。如果这是对密钥的描述，则它属于 KeyInventory 记录，因为客户可能拥有多个密钥。我认为说客户只能拥有一把钥匙是没有意义的。即使您今天的客户碰巧是这样，但将来客户似乎可能拥有多个密钥，也可能允许这样做。

我认为您的库存是非序列化的，即同一把锁的 3 把钥匙没有区别，只是“数量 3”，对吗？如果他们有单独的序列号或其他东西，那么就不会有数量字段，并且每个键都有单独的记录。

于 2013-11-06T22:27:08.130 回答