数据库中是否可以接受反序列化的文件引用？
我遇到的情况是，我需要存储一些不适合数据库表的数据。它有点太抽象了，我没有足够的知识来将其分解为表格和列。相关对象是 System.Linq.Expressions.Expression
我发现了一种使用 MetaLinq 将此类序列化为 xml 的方法。它工作得很好，尽管它生成的 xml 过于肥胖，我对像表达式这样复杂的东西有些期望。一个适度的表达式大约为 19 kb。
所以我的想法是对文件使用 gzip 压缩。这效果很好，可以将其节省到大约 2 kb。
那么，我的实际问题是：基本上使用表列来引用文件名以进行对象的反序列化是不好的做法还是“危险”的做法？就像我有一个表达式表，它有一个文件名，当调用该表达式时，它将执行 gzip 解压缩、反序列化并返回对象。
这似乎是理想的解决方案，但它需要大量文件 I/O 和大量各种压缩/压缩/序列化。我想知道是否可以获得更有经验的数据库管理员的意见。我使用 Fluent nHibernate 作为我的 ORM 映射器。
I have a situation where I need to store some data that just won't ...really fit into a database table. It is a little too abstract, and I've not enough knowledge to piecemeal it in such a way that it could be broken into tables and columns. The object in question is a System.Linq.Expressions.Expression<T>.
I have discovered a means of serializing such to xml using MetaLinq. and it works pretty well, albeit the xml it generates is excessively obese, I somewhat expected this much from something as complicated as an Expression. A modest expression turns out to around 19 kb.
So my thought was to use gzip compression on the file. This works well, it saves it to about 2 kb.
So then, my actual question is this : is it bad practice or 'dangerous' practice to basically use a table column to reference a filename for deserialization for an object? Like I would have a table for expressions, and it would have a filename, when that expression was called it would perform the gzip decompression, deserialize it, and return the object.
This seems like the ideal solution but it requires a lot of File I/O and a lot of various compression/zipping/serialization. I'm wondering if I could get the opinion of more experienced database admins out there. I am using Fluent nHibernate as my ORM mapper.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不是一个经验丰富的 DBA，但我会将序列化数据存储在数据库的 BLOB 字段中。如果数据所依赖的文件消失了，数据库备份就没有任何作用，反之亦然。我认为将所有内容放在一起会简化事情。而且 blob 工作正常，因为不需要查询您存储的数据。
Not an experienced DBA, but I would store the serialized data in a BLOB field in the database. Database backups do no good if the files your data is depending on go away or vice versa. I think it would simplify things to just keep it all together. And the blob works fine since the data you are storing does not need to be queried.
取决于数据的大小。
Sql 现在有表列的 XML 数据类型。因此，您可以反序列化该对象，然后根据大小再次将整个对象插入到列中。
但如果您必须使用文件系统，我会在列中存储路径和文件名。
在您的程序中，app.config 保留驱动器的根目录，例如 \\MyDrive 或 d:\
这样，如果信息移动，只要文件夹/文件结构保持不变，只需更改应用程序配置即可。
编辑：
根据 NerdFury 的建议，如果您不需要“查看”数据库中的数据，您可以使用二进制序列化器。 XML 序列化至少使其可读
Depends on the size of the data.
Sql has an XML data type for table columns now. So you could deserialize the object and then insert the whole object in the column again depending on size.
But if you must use the file system I would store a path and the file name in the column.
In your programs app.config keep the root of the drive like \\MyDrive or d:\
That way if information moves, just change the app config as long as the folder/file structure stays the same.
Edit:
Along with NerdFury suggestion you could you a binary serializer if you do not need to "see" the data in the database. XML serialization at least makes it readable