徐小疼前两天有朋友问到我关于 LITESTAR 4D 的使用问题：要不要专门上一个带开放数据库的程序，把手里所有光度和光谱数据都装进去？他说的是灯具检测实验室的实际情况，一批灯珠测完，IES 文件、LDT 文件、光谱报告散落在好几台电脑上，谁要用都来找他要，版本还对不上，每次做一轮新产品筛选都像在翻旧账。
这个问题我确实被问过很多次，不只是在灯具厂，设计院、工程公司、检测机构都有类似需求。今天这篇回答，我不想直接给一个“要”或者“不要”的答案，而是想从工作流角度聊聊：数据为什么会乱、开放数据库到底解决了什么问题、以及怎样把散落的光度文件、光谱文件理顺。标题里那句“存储所有光度和光谱数据”本身就有个陷阱，后面我会展开说。
1. 先回答标题问题：开放数据库什么时候该上，什么时候先等等
如果你是一个人做照明设计，主要用 LITESTAR 4D 做计算，手头只有几十个灯具文件，那大概率不需要专门部署一套数据库系统。反过来，如果你在一个照明产品研发团队或者检测实验室工作，型号超过两三百个，同一型号还分不同色温、不同光束角、不同驱动版本，那你现在最值钱的东西不是建模技巧，而是数据管理方式。
一个带开放数据库的程序和普通计算软件的区别在于：普通软件把数据锁在内部项目文件里，开放数据库则允许你按照自己的业务逻辑去定义灯具、测量、文件、附件之间的关系。它不是多了一个“保存”按钮，而是意味着你能从一堆历史文件中检索出“2019 年到 2022 年之间，所有 CCT 在 3500K 上下、光通量大于 1500lm、配光为窄光束的产品”，这在文件夹里基本做不到。
1.1 数据为什么总是越管越乱
照明产品的数据天然就是割裂的。一颗灯具的光度数据通常由 IES 或 LDT 文件承载，光色数据可能在一个光谱仪的 CSV 导出里，而电气参数、检测日期、实验室信息又分散在 PDF 报告或 Excel 表里。我们测试时经常收到厂家发来的压缩包，里面文件名像 20240618-03.ies，打开以后根本不知道是哪批光源，更别说确认驱动电流是多少。
另一个乱源是版本更新。同型号灯具换了 LED 光源批次，配光文件可能就变了；如果没留下“旧版本作废、新版本生效”的记录，等软件项目已经做完，才发现计算用的光文件是去年的老版本，这个责任的追查成本非常高。
1.2 出现这几类“病征”，才值得考虑数据库
我建议做一次自我检查，如果你中了三条，就值得认真考虑引入开放数据库。
- 型号数量超过 300 个，且每个型号有多个配置变体；
- 同一型号在一年内做过两次以上重新测试，旧文件依然可能被引用；
- 经常需要按光通量、色温、光束角、显色指数等参数组合筛选灯具；
- 团队多个人会同时查看数据，却由一个人统一管理；
- 每次做招投标或项目报审，都要重新核对产品数据是否和检测报告一致。
满足这些条件后，要不要用 LITESTAR 4D 自带的数据库，还是自己另做一个开放库，关键看你能不能导出、能不能导入、能不能被别人访问。只要这三件事里有一件被厂商锁死，那这个库对你来说只是一个黑盒子，不是在解决存储问题。
1.3 什么样的项目可以先不折腾数据库
反过来说，如果只是做单体项目的照明效果，经常从厂家官网直接下载 IES，项目结束就基本不会再调用，那上数据库反而会拖慢速度。这种场景下，我认为做好文件夹规范就够了：按项目建立目录，命名统一为“厂家_型号_色温_光束角_日期”，再在项目根目录放一个 README 说明文件来源和验证状态，比任何数据库都好用。
不要为了显得“数字化转型”而硬上系统。存储这件事的价值只在数据被重复使用时才产生，如果使用一次就丢掉，那它不值得你花一周时间清洗历史文件。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 存储光度和光谱数据，库结构怎么设计才不踩坑
决定上开放数据库后，你遇到的第一个问题不是下载哪款软件，而是理解自己到底要存什么。很多人在这一步就搞错了，最后库是建了，但数据还是乱的。
2.1 你管的是“文件”还是“数据事实”
文件夹系统里，我们习惯说“那个文件在某台电脑的某个目录”。但在数据库里，真正有价值的是“数据事实”，比如这个型号灯具在 3000K 色温下的光通量是 1200lm，C90/γ45 方向的发光强度是多少，R9 是 62。IES 和 LDT 文件只是这些事实的载体。
把光度和光谱数据拆开看，它们其实不是一类东西。光度数据是一组不同垂直角 γ 和水平角 C 下的光强矩阵，本质上是一张二维表；光谱数据则是一条横轴 380~780nm、纵轴相对强度的曲线序列。两者的查询方式完全不同，所以在建库时最好分开存储，而不是把整份文件塞进一个大 blob 字段里。
2.2 按照灯具型号建模，还是按照测量结果建模
这是最容易犯迷糊的地方。有人直接把“型号名称”当成主键，一个型号一行数据，后来同一型号出了几个色温版本，或者在不同实验室复测出不同结果，旧数字就被覆盖了。这是数据管理的灾难。
一个合格的数据模型应该把“产品”和“测量事件”分开。产品记录的是这个型号应该具备的属性，比如厂商、产品族、接口类型；测量记录则是某一次检测得到的实测结果，包括检测机构、温湿度条件、测量日期、使用的标准。我们不能说某型号在某个方向一定是多少 cd，只能说某次测试在给定条件下测得多少 cd。这样以后复测或者争议溯源时，才能讲清楚数据来源。
2.3 最小可用数据模型：三张表加一张附属表
我自己给小团队推荐过一个最小模型，不需要复杂的数据库知识，用 SQLite 就够跑。先建一张产品表，再建光度测量表，然后建光谱采样表，最后加文件目录表和测量记录关联。
sql复制CREATE TABLE products (
id INTEGER PRIMARY KEY,
manufacturer TEXT NOT NULL,
model_name TEXT NOT NULL,
product_family TEXT,
product_type TEXT,
status TEXT DEFAULT 'active', -- active / archived / obsolete
created_at TEXT DEFAULT (datetime('now')),
UNIQUE(manufacturer, model_name)
);
CREATE TABLE photometric_measurements (
id INTEGER PRIMARY KEY,
product_id INTEGER NOT NULL REFERENCES products(id),
measurement_date TEXT,
laboratory TEXT,
standard_used TEXT,
input_power_w REAL,
luminous_flux_lm REAL,
power_factor REAL,
cct_k REAL,
cri REAL,
peak_cd REAL,
intensity_unit TEXT, -- cd/1000lm 或 cd
measured_file_path TEXT,
file_hash TEXT,
notes TEXT
);
CREATE TABLE spectral_samples (
id INTEGER PRIMARY KEY,
measurement_id INTEGER NOT NULL REFERENCES photometric_measurements(id),
wavelength_nm REAL NOT NULL,
relative_intensity REAL NOT NULL,
is_percent INTEGER DEFAULT 0
);
这里有一个很多人忽略的点：不要直接以 IES/LDT 文件内容作为增删改的根据，最好保留原始文件路径和文件哈希。数据库里记录的是从文件提取出的“可检索字段”和原始文件位置，这样既方便查询，又不用担心数据库字段设计不合理导致原始资料丢失。
3. 动手把零散的 IES/LDT 光谱报告搬进数据库
结构想清楚后，很多人的下一反应是“我要把过去十年所有文件都导入库”。我劝你先别这么做，历史数据清洗是个大工程，很容易让你失去维护意愿。更好的方式是先把规则定好，从新产生的数据开始入库，跑顺后再慢慢回溯。
3.1 先把家底盘清楚，不要跳过命名规范
建库之前，我强烈建议先做一次资产盘点。你不需要马上整理所有旧文件，但要列清楚：
- 手头有多少个灯具型号；
- 每种型号的已有文件分别是什么格式；
- 这些文件是在哪个阶段、由谁、用什么设备测出来的。
盘点后顺手补充命名规范，我认为这是整个数据管理里回报率最高的一步。文件建议按“厂家-型号-色温-光束角-版本-日期”命名，例如：
XX照明-CT2600-3000K-24deg-02-20240618.ies
需要注意，文件和数据库里的名称不要用中文空格或括号，跨系统传输很容易出错。路径也尽量短，避免出现 D:\项目文件\2024年\最终版\新建文件夹\真实最终版 这种结构。
3.2 建库导入时最容易忽略的字段
很多人在导入阶段只顾着把亮度和光通量填进去，后面才发现缺一堆关键字段。最容易遗漏的包括：测试电流和驱动电流、功率因数、环境温度、光源稳态时间、检测机构是否通过认可、文件里的单位和软件界面的单位是否一致。
拿驱动电流举例，同一颗灯珠在 350mA 和 500mA 下测出的光通量可能相差 40%，如果数据库不记录驱动电流，单纯比较两个文件的大小没有任何意义。光谱数据更是如此，有些仪器导出的相对强度是 0~1 的浮点数，有些输出为 0~100 的百分数，库表设计里如果没有说明单位，三个月后自己都看不懂。
3.3 用脚本批量解析光度文件元数据
IES 和 LDT 都是文本格式，可以用脚本批量读取。我这里给一个读取思路，不依赖图形界面的软件，也可以编入自动入库流程。文件一多，手工录入不现实，脚本的好处是生成一个统一的待确认清单。
python复制import hashlib
from pathlib import Path
def file_hash(path):
h = hashlib.sha256()
with open(path, "rb") as f:
for chunk in iter(lambda: f.read(65536), b""):
h.update(chunk)
return h.hexdigest()
def extract_meta(path):
text = path.read_text(encoding="latin-1", errors="ignore")
meta = {"file_path": str(path), "file_hash": file_hash(path)}
if path.suffix.lower() == ".ldt":
# EULUMDAT 第一行通常是生产厂家，第二行通常是灯具型号
lines = text.splitlines()
meta["manufacturer"] = lines[0].strip()
meta["model"] = lines[1].strip()
elif path.suffix.lower() == ".ies":
# IESNA 文件用关键字方式组织
for key in ["MANUFAC", "LUMCAT", "LUMINAIRE", "TEST"]:
for line in text.splitlines():
if line.startswith("[" + key + "]"):
meta[key.lower()] = line.split("]", 1)[1].strip()
break
return meta
这只是一个演示框架，实际项目里还要把光通量、灯数、测量单位等结构化字段解析出来。解析结果先导成检查表，不要直接往库里写，因为文本文件格式千奇百怪，总会有两三个文件不符合标准，需要人工处理。
在处理历史文件时，我还会额外做一步：计算文件哈希，如果两张表里的 file_hash 相同，说明文件内容重复，只是文件名不同。这样可以顺藤摸瓜找出真正的版本差异，而不是被同名文件误导。
3.4 光谱数据入库与证书关联
光谱文件通常不是一份，而是包含了色温、显色指数、色坐标、光谱功率分布。建议把 SP D 的采样点存到 spectral_samples 表，但把 CCT、CRI、色坐标这些“计算结果”放到测量记录主表，方便做条件筛选。入库频率很高的 5nm 间隔光谱，一型号也就几十个点，SQLite 轻松应付。如果采样间隔到 0.5nm，单条曲线几百个点，建议把原始文本文件作为附件存文件路径，入库表只放间隔标识和文件路径，否则以后做条件查询时数据表会非常臃肿。
检测证书和测试报告 PDF 最好也做关联。数据库里不需要把 PDF 转成二进制存进去，而是在测量记录表里增加一个证书文件路径字段。库只负责告诉你“哪个文件对应哪份报告”，原始文件统一放进受控文件夹。这样即使以后更换数据库软件，原始记录也不会丢。
4. 存储选型与备份：SQLite、PostgreSQL 怎么选
经常有人问我：“要不要装一个大数据库软件？”其实很多人理解错了，数据库不是一个越复杂越好的东西，关键是匹配你的协作场景。
4.1 单机够用还是必须上服务端数据库
三种方案对比：
| 场景 | 合适方案 | 理由 |
|---|---|---|
| 一个人维护数据，偶尔要查询 | SQLite | 单文件，打开就能查，备份简单 |
| 两三个人在局域网同时使用 | SQLite + 文件目录只读共享 | 多数时间是查，写入频率低时可以忍受 |
| 团队多人频繁新增、修改、并发查询 | PostgreSQL | 支持可靠并发和权限管理 |
| 需要让 LITESTAR 4D 等程序定期读取同一批数据 | 文件目录同步或服务端数据库 + 导出接口 | 数据库不在计算软件内部，避免绑定，软件只管消费 |
我见过不少工程师一上来就用 Docker 跑 PostgreSQL，但根本不具备维护能力，光是一个容器重启失败就折腾半天。对单人工作流而言，SQLite 已经是“具有开放数据库思维”的好选择，因为它不锁定格式，任何能读 SQL 的工具都能操作。LITESTAR 4D 或其它计算程序是数据库的消费者，数据存储本身应该尽量与具体软件解耦。
4.2 数据库文件的存储路径、共享与迁移
如果你用 Docker 跑 PostgreSQL，数据卷的路径一定要提前规划好，不要默认放在系统盘。拿我个人项目举例：
bash复制docker run -d --name litestar-data \
-e POSTGRES_PASSWORD=ChangeMe \
-v /data/litestar-db:/var/lib/postgresql/data \
-p 5432:5432 \
postgres:16
尽量把数据库目录放到有固态盘且剩余空间充足的位置，否则后期大量光谱点写入时会有明显卡顿。另一个容易踩的坑是，千万不要把 SQLite 数据库文件直接放在 NAS 的 SMB 共享目录里供多人写入。SQLite 本身适用于单机，网络文件系统的文件锁机制不可靠，并发一高很容易出现数据库损坏。要么只读共享，要么换 PostgreSQL。
无论用哪种，备份策略都比数据库软件本身重要。我的习惯是数据库每日备份一次，原始 IES/LDT/PDF 文件每日增量同步，备份至少保存三份：一份本机外置盘，一份局域网 NAS，一份云存储。备份内容不能只备份数据库文件，因为如果原始光文件和检测证书丢了，光有数据库里的元数据也补救不回来。
4.3 与 LITESTAR 4D 工作流联动的正确姿势
有开放数据库后，你要想清楚它和 LITESTAR 4D 之间的关系。照明计算软件擅长的是光环境模拟，不是数据管理系统。如果你把数据库当成单一事实源，那 LITESTAR 4D 就只是一个读取数据、做计算和分析的窗口。
如果没有现成插件，最稳妥的联动方式是：数据库负责维护“标准文件输出目录”，按某条规则导出 IES/LDT，然后让 LITESTAR 4D 索引这个目录。比如我常按产品族建输出目录，数据库里只保存字段和文件位置，计算软件需要的文件仍然从目录读取。这样既不会因为换软件导致历史数据失效，也能让不懂数据库的人照常使用原有工作方式。
5. 常见问题与避坑经验实录
5.1 单位不一致导致的数据“假对比”
光度文件里最容易出问题的是发光强度单位。部分 IES 文件里存的是绝对光强 cd，部分 LDT 文件里存的是 cd/1000lm 的归一化值。如果把两种文件直接放进同一张表做对比，会得到完全不科学的结论。
我建议每次导入时除了解析光强数值，还必须解析或手动确认单位字段。可以在 IES/LDT 解析时看文件头部的测试条件，也可以在导入界面设置一把下拉框。数据库表里增加一列 intensity_unit，记录当时导入时的单位。后续比较不同灯具时，先把归一化单位统一换算到 cd/1000lm，再排序和筛选，否则很容易被“看起来更亮”的文件误导，其实它只是数值表示方式不同。
5.2 光谱库膨胀后查询变慢怎么办
光谱数据如果不加节制地逐点存储，三五年后查询会明显变慢。我处理过一家实验室的数据，光谱扫描频率高，一年就产生上千万行采样点，简单查询都要好几秒。
我的处理思路是分两层：主数据库只存每条光谱的摘要指标，包括 CCT、色坐标、显色指数、光通量、测试时间和文件路径；原始高密度采样点放在按年份归档的文件系统里。需要看曲线时，通过摘要记录里的 file_path 快速读取对应 CSV。如果你非要让所有采样点都进库，那就要在 wavelength_nm 列上建索引，并且不要同时保留原始 text 文件和重复的采样点，否则数据库体积会失控。
5.3 多人协作时如何避免误改和版本混乱
多人协作最大的风险不是导入出错，而是有人不小心把正在使用的生产数据改掉。数据库里的数据不能像聊天工具传文件那样“大家都能随便改”。我建议给团队里的人分清楚等级：数据维护人员有写入权限，设计师和销售只读，而且检索结果里必须能看到测量日期、实验室、文件哈希这些溯源字段。
当同型号灯具重新送检后，不要删除旧测量记录，应该把旧记录状态标记为 archived 或 obsolete，新增一条状态为 active 的新记录。产品进入计算软件时，默认只调取 active 状态的测量结果。如果之后发现新旧数据差异很大，还能回来对比两个版本，确定是批次问题还是标准变化。
5.4 给零基础团队的最后一句建议
如果你现在正面对一堆乱糟糟的光度和光谱文件，别指望一口吃成胖子。先把文件名改规范，把新入库的数据流程跑通，再用三个月时间验证查询场景是否够用，最后才去回溯旧文件。我见过太多团队一开始雄心万丈要把所有历史数据一次整理完，结果项目推进两周就烂尾，连新数据也没人愿意录。
真正让数据库能长期跑下去的因素，不是软件功能多强大，而是录入流程足够简单、字段规则足够清晰、备份机制足够可靠。把这些基础打好，你手里的每一个 IES、每一份光谱报告，才会变成随时能调用、能对比、能共享的数字资产，而不是躺在硬盘里吃灰的孤岛文件。