MSSQL建数据库时，数据库约束，是用还是不用？
几乎在所有的MSSQl的教种中，都说为了满足数据的完整性，必段要用到各种约束(primary key,unique,foreign key,check),可是在实际的APP开发中，发现数据库约束并不好用，比如你的数据表中有一个IP地址列，你在MSSQL中怎么去实现check约束来保证其是一个IP地址？还有比如表中有一个字段的值要是1至10之间，你建立了check约束，难道你在客户端就不在验证用户的输入(比如客户端输入了30,难道这个30直接让它传回数据库，让数据库产生错误代码，客户端再处理），既然客户端还是要在传送数据到SQL之前做客户端数据的有效性验证，sql约束不显得多余吗，而且对性能应该也会有影响。还有外键约束，级联操作，看起来数据库实现得很好，可是你用的时候发现很多时候不能满足要求，用应用层去实现会更灵活更简单。所以想问问大家，数据库约束，到底是用呢还是不用的好？
------解决方案--------------------
你的想法有点偏激了，约束的确可以保证完整性，但是你要记住，不要把什么东西都丢到数据库去帮你实现，要实现“合作”，比如你说的“还有比如表中有一个字段的值要是1至10之间，你建立了check约束，难道你在客户端就不在验证用户的输入”这句，应该前端程序和SQLServer都要做，个人觉得主要是双保险把，同时如果前端判断好了，那么可以在一定程度上减轻SQLServer判断所带来的负担。也就是说客户端判断不行，那么就不传进SQLServer，SQLServer自然就不用判断了。但是你能确定一定有完美无缺的应用程序吗？不管你信不信，反正我是不信的。那么还是要保留一个第二层保险，数据一旦进入数据库，要改动并不是你想象中的容易。你的问题我就不一一回复了，总的来说，一个功能有其优缺点，具体情况具体分析是万能的答案。有时候你觉得“多余”的东西可能会在你遗漏的时候救你一把。
------解决方案--------------------
建数据库约束，是确保正确数据进入数据库中的最后把关，如果省去这不，即使你程序的到的结果是你认为正确的数据，但实际保存到数据库时，数据因为各种原因，导致进入数据库的数据与程序的判断冲突，这时因为没有数据库约束的保障，导致你保存错误的数据到数据库中，所以向楼上的说法，双重保险，确保数据正确
------解决方案--------------------
LZ必须换个思路，该双保险进行验证的必须双保险，万一程序进行改动怎么办？我们学习SQL不是为了什么事情都用SQL完成，而是为了更好的完成项目，所以最终的目的是选择更好的办法，SQL只是工具，它只是用来帮助我们的，而不是一味的最求工具怎么样，如果工具达不到我们的要求，不如不用。