通过实体框架在 SQL Server 2008 中存储文档的数据类型
我正在尝试使用实体框架在 SQL Server 2008 中存储文档。
我相信我已经完成了执行此操作的代码。我现在面临的问题是在 SQL Server 和我的实体模型中使用哪种数据类型。
“图像”是我的第一选择，但这会在我更新模型时导致“无效映射”错误。我发现没有“图像”的等效项（通过实体属性中的“类型”下拉列表）。
然后我尝试了“varbinary(MAX)”，我发现这映射到实体模型中的“binary”。但是，当我运行代码时，它告诉我数据将被截断，因此它停止了。经过调查，我发现 SQL Server 数据类型“binary”的长度为 8000 字节 - 这就是我选择“varbinary(MAX)”的原因 - 因此实体模型似乎正在将“varbinary(MAX)”减少/映射为“binary” 。
这是对的吗？
如果是这样，我的数据类型应该是什么（在 SQL Server 2008 和我的实体模型中）？有什么建议吗？
I'm trying to store a document in SQL Server 2008 using the Entity Framework.
I believe I have the code for doing this completed. The problem I'm now facing is which Data Type to use in SQL Server and in my entity model.
'Image' was my first choice, but this causes an "Invalid mapping" error when I update the model. I see that there's no equivalent of 'Image' (going by the Type drop-down in the entity's properties).
So then I tried 'varbinary(MAX)' and I see that this maps to 'binary' in the entity model. However, when I run the code it tells me that the data would be truncated so it stopped. Upon investigation I see that the SQL Server Data Type 'binary' is 8000 bytes long - which is why I chose 'varbinary(MAX)' - so the entity model seems to be reducing/mapping 'varbinary(MAX)' to 'binary'.
Is this right?
If so, what should my Data Types be (in both SQL Server 2008 and in my entity model) please? Any suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
将模型的数据类型更改为 byte[] 就可以了，如果您需要更多解释，请发表评论。
编辑：
伙计，我之前在 Linq to Sql 中尝试过，这次我在 EF 中尝试过，在你的 Foo.edmx 文件的概念模型中，你的类型是二进制（你可以通过 Visual Studio 的上下文菜单打开它，然后选择 Xml 编辑器或任何其他文本编辑器（如记事本），但在生成的名为 Foo.designer.cs 的文件中，您的数据类型为 Byte[]。
而且没有你上面提到的限制。
我尝试使用 10000 字节，它已成功插入，而没有截断我的数组。关于在数据库或文件系统中保存文档的基准测试我读了一篇文章，它说在 Sql Server 7 中，文件系统在检索存储的数据方面具有更好的性能，但在更高版本的 Sql Server 中，它接管了文件系统的速度，并且它建议将文档保存在 Sql Server 上。
恕我直言，关于保存文档，如果它们不是太大，我更喜欢将它们存储在数据库上（据我所知，NoSql 数据库在这里具有出色的性能），
第一：我的数据的完整性，
第二：你可以拥有更多的性能（因为如果您的文件夹有大量文件，那么在这些文件夹中读取和写入文件的速度会逐渐变慢，除非您将它们组织在多个文件夹中，最好是树状文件夹中），
第三：您可以应用到它们的安全策略更轻松地通过您的应用程序（虽然您可以在文件系统方法上执行此操作，但我认为这里更容易）
第四：您可以从 DBMS 提供的用于查询和操作的设施中受益，并且......这些文件
以及更多......： -)
Change the data type of your model to byte[] and it will be all right dude, if you need more explanations please leave a comment.
EDIT:
Dude, I had tried it before in Linq to Sql and this time I tried it in EF, in conceptual model of your namely Foo.edmx file your type is Binary(you can open it through open with context menu of Visual Studio and then selecting Xml Editor or any other text editor like notepad) but in a generated file named Foo.designer.cs your data type is Byte[].
And there is not a limit you mentioned above.
I tried it with a 10000 bytes and it's inserted successfully without truncating my array. About benchmarking on saving documents in database or file system I read an article and it said that in Sql Server 7, file system have a better performance on retrieving stored data but in later versions of Sql Server, it take over the file system speed and it suggested saving documents on Sql Server.
IMHO on saving documents, if they are not too large, I prefer to store them on DB (NoSql DBs has great performance here as far as I know),
First: Integrity of my data,
Second: More performance that you can have(cause if your folder has large number of files, reading and writing files in those folder slows down gradually more and more unless you organize them in more than one folder and preferably in a tree like folders),
Third: Security policies that you may apply to them through your application more easily(although you can do this on file system approach but i think it's easier here)
Fourth: you can benefit from facilities provided by your DBMS for querying and manipulating and ... those files
and much more ... :-)
理想情况下，您不应将文档存储在数据库中，而是将文档路径存储在数据库中，然后该路径指向 Web 服务器本身（或其他存储、CDN 等）上的物理文档。
但是，如果您必须将其存储在 SQL Server 中（就像在 SQL 2008 上一样），
您应该使用 FILESTREAM。
并且它受 EF4 支持（我相信）。它映射到二进制。
正如我所说，我不确定它的性能如何，请运行一些基准测试 - 如果性能不太好，请尝试使用常规 ADO.NET/FileStream API。
我仍然认为你应该把它放在文件系统上，而不是数据库中（当然是我的意见）
Ideally you should not store documents in the database, instead store the path to the document in the database, which then points to the physical document on the web server itself (or some other storage, CDN, etc).
However, if you must store it in SQL Server (and seeing as though your on SQL 2008),
you should be using FILESTREAM.
And it is supported by EF4 (i believe). It maps to binary.
As i said though, i'm not sure how well this will perform, run some benchmarks - and if it's not performing too well, try using regular ADO.NET/FileStream API.
I still think you should put it on the file system, not in the database (my opinion of course)