Warning: file_get_contents(/data/phpspider/zhask/data//catemap/3/sql-server-2005/2.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Sql server 2005 在价格和价值方面,使用varchar比使用decimal有什么优势吗_Sql Server 2005_Database Design_Types - Fatal编程技术网

Sql server 2005 在价格和价值方面,使用varchar比使用decimal有什么优势吗

Sql server 2005 在价格和价值方面,使用varchar比使用decimal有什么优势吗,sql-server-2005,database-design,types,Sql Server 2005,Database Design,Types,我和我的朋友争论,反对他在varchar中存储价格、价值和其他类似信息的建议 我的观点是基于 计算将变得困难,因为我们需要反复计算 数据的完整性将丢失 索引性能差 排序和聚合函数也需要强制转换 等等等等 但是他说,在他以前的工作中,每个人都用varchar存储这样的值,因为在这种方法中,DB和应用程序之间的通信将非常有效。(我还是不能接受) 将这些值存储在varchar中真的有好处吗? 注意:我不是说像PhoneNo、IDs、ZIP Code、SSN等列。我知道varchar最适合这些列。这些列

我和我的朋友争论,反对他在varchar中存储价格、价值和其他类似信息的建议

我的观点是基于

  • 计算将变得困难,因为我们需要反复计算
  • 数据的完整性将丢失
  • 索引性能差
  • 排序和聚合函数也需要强制转换
  • 等等等等

    但是他说,在他以前的工作中,每个人都用varchar存储这样的值,因为在这种方法中,DB和应用程序之间的通信将非常有效。(我还是不能接受)

    将这些值存储在varchar中真的有好处吗?

    注意:我不是说像PhoneNo、IDs、ZIP Code、SSN等列。我知道varchar最适合这些列。这些列是基于值的,肯定会以某种方式参与计算。

    完全没有

    试着将一个值转换回来,看看你丢失了多少数据

    DECLARE @foo TABLE (bar varchar(30))
    INSERT @foo VALUES (11.2222222222)
    INSERT @foo VALUES (22.3333333333)
    INSERT @foo VALUES (33.1111111111)
    SELECT CAST(CAST(bar AS float) AS varchar(30)) FROM @foo
    

    我还想说的是,他目前的工作方式有所不同。。。他不再是以前的雇员了……

    我认为使用适当(在本例中为十进制)数据类型的一个重要原因是为了防止无效数据。没有什么可以阻止某人在varchar字段中输入“theking”作为价格。

    数据类型最好存储在与两个不同系统之间的类型匹配的字段中。在本例中,您将从.Net对象引用MS SQL server。对于数据完整性丢失和将数据类型转换为可用表单的需要,您是正确的。至于其他类型,如电话号码、邮政编码、SSN等;它们也将受益于专用数据类型。这些存储在VARCHAR/NVARCHAR中的主要原因是,并非每个系统都需要许多不同的可能性。但是,如果您有一个常用的类型,并且希望对其进行约束,则可以构建名为的自定义数据类型,以将该数据存储在SQL server中。(更有趣的是CLR定义的类型,请参见上的示例。)

    我看不出有什么优点,还有一大堆非常严重的缺点——其中最紧迫的是性能(尤其是排序时)

    考虑一下,如果您想要获得N个最昂贵产品的列表,并且您将价格存储为VARCHAR。以下是一些示例值(按降序排序)

    哎呀!排序顺序错了!(字母数字排序,而不是值排序)


    如果我们想正确地进行排序,那么这意味着我们要么需要在开始时用零填充值,要么在排序之前将每个值转换为双精度-但是如果我们必须对每一行进行转换,这意味着SQL server无法使用统计信息来预测结果!这反过来意味着性能非常差,可能是一次表扫描。

    正如Kragen指出的,排序不一定会按正确的顺序进行

    比较也未必有效。如果一个字段被定义为十进制(8,2),我给它一个值“37.20”,然后我写下“select…where price=37.2”,结果将是真的。但是如果我存储一个varchar 37.20并将其与37.2进行比较,它将不相等。类似地,如果一个或另一个有前导零

    您可以通过让应用程序确保始终使用固定的小数位数存储数字,并用前导零填充来解决这些问题。哦,还要确保你对减号的存储有一个一致的约定。但是,应用程序中写入此字段的每个位置都必须确保它遵循完全相同的规则。我们当然可以这样做,但为什么呢?如果我们只声明字段numeric,数据库引擎将为我们执行此操作。比如,是的,我可以用剪刀修剪草坪,但我为什么要这样做呢


    我不明白你的朋友在说什么优势应该是什么。应用程序和数据库之间的通信更方便?怎么用?也许他使用了一些非传统的语言或数据库接口,无法从数据库中读取数值。我从来没有遇到过这个问题。事实上,这么说让我想知道这是否是发生的事情:在他以前的公司,由于实现问题,他们使用的某种语言或工具无法从数据库中读取小数,他们能够让它工作的唯一方法是将所有数字声明为varchar,现在他走开了,认为这是个好主意。

    好的。一个字的回答。不要

    关于影响性能的正确数据类型(SQL Optimizer对INT和VARCHAR的工作方式不同)、数据一致性和完整性等,您是对的

    如果我们只需要瓦查尔,我想我们从来没有发明过其他类型的。 SQL不是动态类型的。静态类型使优化效果更好,索引页更小,查询操作符效率更高

    消费者需要所有字符串作为输入,这不是源代码的问题。由用户进行类型检查和使用数据。数据库应始终具有正确的类型


    (忘了在INT和VARCHAR之间进行选择吧,我想说,您还应该考虑是使用INT还是TINYINT)这些考虑带来了很大的不同

    我可以看到,使用任何类型的可变大小字符串ish格式的唯一好处是,字段必须容纳未知数量的附加信息。例如,“49。95@1/39.95@5/29.95@20/14.95@100,match=true/24。95@100“表明此特定产品的价格点为1、5、20和100个单位,并且只有在所有项目都相同时才提供最佳100个单位的价格。使用字符串来存储这样的东西是令人讨厌的,但是如果价格点数是开放的,那么使用一个可变大小的字段可能比创建另一个包含一行的表要好
    SELECT Price FROM Table ORDER BY Price DESC
    
    Price
    -----
    
    90
    600
    50
    1000