内置库似乎不太适合存储文件

本想做个测试向内置数据库插1000张4M的jpg文件

按道理也只有4G不到的空间
但直接把我10G的C盘干爆了



换成sqlserver2016再来
空库容量

导入1000条后容量

导入消耗的时间



表格每页加载10条，翻页的时间在25秒左右


总体反应比较缓慢

sqllite本身就属于轻量型数据库，有优点自然就有缺点，大佬可以参考下这篇文章~~

https://blog.csdn.net/weixin_49370884/article/details/126095649

内置库只适合测试，或者很简单的业务，数据量大一定选择大型关系型数据库 MSS  Mysql Oracle

把图片数据的存储类型从base64的nvarchar换成image类型，速度大幅提升，由原来的28秒提升900毫秒，这个差别还是很大的

按照最佳实践来做，推荐直接用MySQL、MSSQL等主流数据库。

赛龙周 发表于 2024-12-24 15:05
把图片数据的存储类型从base64的nvarchar换成image类型，速度大幅提升，由原来的28秒提升900毫秒，这个差别 ...

image还有这效果呢，我试试，base64存到text字段中，每次打开表，活字格都死。

image  存储的是  图片文件的路径。

Syl 发表于 2024-12-24 12:01
内置库只适合测试，或者很简单的业务，数据量大一定选择大型关系型数据库 MSS  Mysql Oracle

友情提示：SQLite和MySQL的数据库脚本不兼容。如果你基于SQLite开发了一个简单的业务，但是写过视图和执行SQL命令，以后基于该业务扩展其他功能需要切换数据库时，可能会很痛苦。

olookok 发表于 2025-1-3 08:18
image  存储的是  图片文件的路径。

我这image是SQL server的一种数据类型，专门用来以二进制的形式存储大文件

在新的版本中，推荐使用VARBINARY(MAX)


CREATE TABLE Images (
    ID INT IDENTITY PRIMARY KEY,  
    ImageData VARBINARY(MAX)               
);

INSERT INTO Images (ImageData)
SELECT * FROM OPENROWSET(BULK 'C:\path\to\your\image.jpg', SINGLE_BLOB) AS Image;

SELECT ImageData FROM Images WHERE ID = 1;

UPDATE Images
SET ImageData = (SELECT * FROM OPENROWSET(BULK 'C:\path\to\your\new_image.jpg', SINGLE_BLOB) AS Image)
WHERE ID = 1;