关于sqlserver2014字段类型的使用？用错了有问题吗

[仙侣步惊云]

一、存贮汉字
有char、varchar、nchar、nvarchar，对于存贮汉字，汉字、数字、字母的，应该使用哪个类型？
问了一些人，说就用char通吃，没必要用其它类型。
二、存贮图片
有image、binary、varbinary

据说应该用varbinary存贮图片，image在未来版本可能弃用？
三、存贮人民币
有decimal、money，似乎用decimal(10,2)这样还方便些？
客户端开发使用delphi这类工具，还得考虑数据交互的兼容性，一旦设计好录入大量数据，如果发现数据类型搞错了，将是灾难性的。
请教有丰富经验的师傅。

[仙侣步惊云]

将图片存在在文件夹中，总感觉不放心，可能丢失、感染病毒，操作也不如存入图形字段方便。

[Dear SQL(燊)]

引用 2 楼 sxqwhxq 的回复:

将图片存在在文件夹中，总感觉不放心，可能丢失、感染病毒，操作也不如存入图形字段方便。

做好备份

[吉普赛的歌]

一、存贮汉字
有char、varchar、nchar、nvarchar，对于存贮汉字，汉字、数字、字母的，应该使用哪个类型？
问了一些人，说就用char通吃，没必要用其它类型。
--汉字、特殊字符 用 nvarchar
--字母、数字 用 varchar
--( char 在长度不一的情况下填充，浪费空间又可能引起误会。何况中文用 char 也不行 )

二、存贮图片
有image、binary、varbinary
据说应该用varbinary存贮图片，image在未来版本可能弃用？
-- varbinary
-- 或仅保存 图片路径（特别数据量大的情况下最好是只保存路径）

三、存贮人民币
有decimal、money，似乎用decimal(10,2)这样还方便些？
客户端开发使用delphi这类工具，还得考虑数据交互的兼容性，一旦设计好录入大量数据，如果发现数据类型搞错了，将是灾难性的。
-- decimal(10,2) 精度要跟实际业务单位商量好，可以设置大点

[仙侣步惊云]

版主大人，图片存贮在数据库内，与存贮在文件夹内，从本质上说，都是存贮在硬盘内。
如果从管理效率和使用效率上，似乎贮存在数据库内更方便，因为数据库系统有一套磁盘优化存贮技术，但感觉成千上万的图片文件存贮在文件夹内，有种散乱、没有一体化管理的感觉，而且文件容易丢失，影响数据的唯一性、可靠性。您说呢？

[仙侣步惊云]

对于向delphi这类cs/bs客户端开发工具，从服务器上打开一个文件到客户端，没有从远程服务器上读取数据字段来得方便。

[吉普赛的歌]

管理效率上， 数据库可能方便了一点， 但使用效率绝对是低的， 能有直接使用文件的几分之一都不错了。 如果是大文件， 放数据库可能还要差。 这是数据库本身的机制决定的， 无法提高。 互联网化的公司， 基本不可能放数据库。因为他们对文件存取的要求比较高。 你可能用 C/S 程序比较多， 所以对这个不太敏感。 用文件夹， 如果愿意去在程序方面做点处理， 可以用日期文件夹分类 /2018/12/19/xxx.jpg 或者 业务文件夹分类 /department/devopler/xxx.jpg 其实也非常清晰的。 至于说丢失， 数据库丢失的可能性会更大， 数据库如果损坏， 可能啥都没有了， 一个图片都找不到…… 见过有人用 sqlserver 做 tfs 版本控制， 结果数据库损坏无法修复， 服务器内所有源代码丢失…… 放文件夹， 你一样可以用 批处理来对图片文件夹作备份。 或者用一些工具将某图片同步到另外一台机。 担心文件丢失， 你甚至可以做一个扫描程序， 每小时核对一遍数据库路径与实际存储的文件， 有问题就立即发邮件给你。 有兴趣， 你可以去了解一下 FastDFS， 这是专门的 Linux 文件服务器， 上传和查询非常方便。 网盘大多数都是用这个做的。

[Dear SQL(燊)]

强烈不建议图片保存在表中，我们一个旧的系统一个表保存了图片有200多G还在增大，现在表加字段都困难还有性能问题

[Dear SQL(燊)]

如果硬要保存在表中，记得把图片字段独立出来存另一个表，用主键关联取数

[吉普赛的歌]

https://www.cnblogs.com/panchunting/p/SQLServer_FileStream.html 这个文件表也不错，如果你用的 sqlserver2008+, 推荐你看看。

[吉普赛的歌]

引用 11 楼 sxqwhxq 的回复:

可是，若有500万个1M以下的文件，大约会使数据库增大5000G，在500万条记录，有主键的表中找到该记录应该是毫秒级； 若500万个文件夹，在磁盘内搜索到此文件，应该至少是分钟级，而且，存贮500万个1M的文件，可能不止5000G。 一个5000G的数据库，如果把图片放在专门的表中，有大多可能影响该数据库其它表的查询？应该影响是不大的。 问题是，没有那个硬盘分区会有5000G，如果采用文件操作的方式，可能要架设专门的文件服务器。

你想太复杂了， 图片放文件夹哪里需要这么长时间？如果都要等1分钟才出来， 人家网站不早就卡死了？ 你的数据库表， 已经存储了文件的路径，根据主键直接可以拿到， 再去读那个文件就可以了。 所谓的寻址时间， 这个都很小可以忽略不计。 区别只是读文件和读数据库的差别。 程序从数据库读一条带1MB图片的记录， 与读一条普通的记录， 肯定是有差别的， 1ms应该是做不到。 存储上， 没做过测试， 但存放数据库应该不会比放文件夹占用的空间更少。 这个方面的争论也没有益处， DBA重在动手能力， 你可以亲自做一个评测， 写一篇博客。 如果你的文件都很小，而且只是用于 C/S ， 也没有往 B/S 发展的需求， 那放数据库也关系吧。 这个没有谁对谁错， 结合自己熟悉的技术、业务需求来就好了。

[吉普赛的歌]

做了个简单评测， 区别不大： https://blog.csdn.net/yenange/article/details/85122965

[仙侣步惊云]

可是，若有500万个1M以下的文件，大约会使数据库增大5000G，在500万条记录，有主键的表中找到该记录应该是毫秒级；
若500万个文件夹，在磁盘内搜索到此文件，应该至少是分钟级，而且，存贮500万个1M的文件，可能不止5000G。
一个5000G的数据库，如果把图片放在专门的表中，有大多可能影响该数据库其它表的查询？应该影响是不大的。
问题是，没有那个硬盘分区会有5000G，如果采用文件操作的方式，可能要架设专门的文件服务器。

[仙侣步惊云]

这个，也许只有做个档案信息化扫描的工程师，才有心得。

[仙侣步惊云]

@版主
varbinary(n)，既然是可变长度，为何还要设置n呢？n设置小了会截断，大了浪费空间，还不如使用image存贮图片。

[Dear SQL(燊)]

varbinary(n) 可变长度二进制数据,跟varchar,nvarchar 一样有的你存进去数据多长就占多长，当然n过小会截断的

[吉普赛的歌]

引用 16 楼 sxqwhxq 的回复:

@版主 varbinary(n)，既然是可变长度，为何还要设置n呢？n设置小了会截断，大了浪费空间，还不如使用image存贮图片。

既然前面有 "var" ， 那就是可变长度， 需要多少给多少， 哪里谈得上浪费呢？ 至于 n , 设置有一定意义。 因为 sqlserver 每行的大小是固定的（8KB），如果本身设置过大，则将另外分配 如果 前面也说了， image 是废弃类型， 当然不是首选。 https://docs.microsoft.com/zh-cn/sql/t-sql/data-types/ntext-text-and-image-transact-sql?view=sql-server-2017

[仙侣步惊云]

我还是没明白，存贮图片或文档时，应该设置varbinary的n为多大。

[Dear SQL(燊)]

varbinary [ ( n | max) ] 可变长度二进制数据。 n 的取值范围为 1 至 8,000。 max 指示最大存储大小是 2^31-1 个字节。 存储大小为所输入数据的实际长度 + 2 个字节。 所输入数据的长度可以是 0 字节。 varbinary 的 ANSI SQL 同义词为 binary varying。

[Dear SQL(燊)]

设成max够用了

[仙侣步惊云]

哦，不须指定n了，直接max ，谢谢。