2011-01-27 67 views
2

我们正在设计一个管理联系人信息的应用程序。允许用户即时将数据列添加到其数据库的最佳方式是什么?

客户的要求之一是允许他们的高级用户或管理员工通过用户界面向数据库添加列。客户无法直接访问数据库(即无法使用SSMS打开并进行更改)。

我看到的控件有:1)输入字段的名称,2)输入数据类型,3)选择要添加字段的表。一旦用户点击一个按钮,数据库将更新为新的字段。我需要检查适当的权限,该字段是否已经存在等。我们还需要将表单字段连接到这个新字段,例如报表设计器界面。

  1. 我在哪里可以找到一个示例显示我想要做什么?
  2. 这样做有什么缺点?除了这么做的开发者看起来是一份体面的工作。
  3. 你会推荐这样做吗?如果不是,什么是更好的解决方案?

编辑 - 我们需要使用SQL Server。不可议价。

+0

你使用`sql server`锁定了吗?也许像`mongodb`这样的无模式数据库更适合您的问题。 – Chris 2011-01-27 22:46:04

+0

*最好的办法*做到这一点? **不!** – 2011-01-28 05:48:32

回答

11

这是绝对的要求,他们添加列到表,或只是他们能够指定额外的领域来存储?我强烈建议你考虑像Entity-Attribute-Value之类的东西,而不是让最终用户(管理员作为最终用户)来进行模式更改。

对于这样的事情,您需要一个表来定义您的自定义字段,然后是多对多关联表,以允许用户为联系人的自定义字段指定一个值。例如:

Contact 
    --------- 
-> ContactId 
| FirstName 
| LastName 
| etc. 
| 
|      ContactField 
|      -------------- 
|      ContactFieldId <--- 
|      FieldName   | 
|           | 
| ContactFieldValue      | 
| -------------------      | 
-- ContactId        | 
    ContactFieldId ------------------------- 
    Value 

实现的细节显然是由你(例如,是否使用ContactId + ContactFieldIdContactFieldValue复合主键),但这应该传达出的总体思路。

2

参考此链接的解决方案:C# Dynamically Add Columns to table in Database

老实说,我认为,让用户控制添加列可能是不这样做,因为它是被滥用的最好的事情。而用户在技术上可能并不了解数据库结构。而且表之间的多对多关系会发生什么。

希望这会有所帮助。

1

处理这种情况的简单方法是预先定义6个(或其他)“备用”列,并且有一个额外的表,该表可以从您给列的名称映射到名称你向用户展示。如果它为空(例如),则不会在窗体上显示该字段,但如果它非空,则显示具有该名称的字段。这样他们可以自定义,但不会改变表格本身(可能是相当于在大表格中缓慢)。

0

您必须确保用户不超过最大记录大小。不确定2008年如何响应DDL,这会导致行超过行的最大字节数。 http://msdn.microsoft.com/en-us/library/ms143432.aspx - 如果你还不知道,可以测试一下。

我不会推荐这个。但是,国际金融机构都这样做,我会做的UI交互性和简单化向下:

  What kind of field do you want to add? 
       Date-time 
       number without a decimal point 
       number with a decimal point 
       little text note 
       large text note 
       image 
       yes/no 
       etc etc 
0

有趣的命题 - 让他们进行更改的数据库,但不允许他们使用设计的工具目的?

我建议给他们两个数据类型,一个nvarchar最大长度和一个数字(如果可以,则为整数,如果他们需要,则为十进制)并查看得到它们的距离。

但是,如果您尝试构建太多限制条件,我希望您会有一个永无止境的过程来确定在不损害自己或其他人的情况下做好自己的工作。 (太多了,他们会自我伤害 :)即使是专业人员也会伤害自己。)

4

我强烈推回要求,让他们知道这是一个非常糟糕的主意。是的,你可以为这些表添加一个EAV表,但是你有问题,查询它既不简单也不表现。或者,您可以像@Jerry Coffin所建议的那样,使用六张备用栏目的表格,但他会导致报告困难,并且在他们全部使用它们时会发生什么情况。所有这些都导致开发人员进行大量额外的工作,以支持一年内可能不会导致3次数据库更改的要求。您冒着数据完整性,数据库性能和报告准确性的风险(我敢打赌,这些新字段不会有PK/FK关系或默认值,或者甚至是正确的数据类型,因此日期是变化的,因此数据将被添加到数据库中的会费日期是ASAP,不适用于报告),以及所有不知道他们在做什么的人都可以假装进行数据库更改,这些数据库更改效率低下,思路不清。

我已经与许多COTS产品合作过,当人们实际添加列时(实际上很少有人足够勇敢地这样做)。他们没有按照他们需要的形式出现,他们也不会自动添加到报告中,他们通常无法搜索,并且在每种情况下,他们最终花费更多的钱去解决他们制作的数据混乱问题让专业人员进行设计更改会有成本。

大多数时候,当我看到这样的要求时,高级管理人员认为灵活性很酷,而不是任何高级用户实际需要甚至想要这样做。他们需要意识到他们所要求的成本。

花费更多的时间和额外的几天与高级用户谈论他们需要的东西并获得设计开始的权利,而不是走下这条路。

这是真正需要长时间严肃讨论的要求之一,它不仅需要开发时间花费多少,而且数据完整性和性能以及可维护性几乎没有增益。我会做一个正式的成本效益分析,以向他们展示这个想法到底有多糟糕。然后,一旦他们完全沉浸于他们所要求的完全愚蠢的行为,如果他们仍然需要它,继续建设并开始寻找新的工作,因为你不想成为一个必须维护的人这个。

相关问题