如何处理数据库字段是bigint型?

本文探讨了在从数据库读取bigint类型字段到程序中int类型变量时可能遇到的异常情况,并提供了有效的解决方案,建议使用Int64类型的变量来避免溢出错误。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

数据库字段ID是bigint型,在执行某个存储过程后,其中存储过程SQL是这样的:select ID,…………
 
在程序中声明了变量是int型,在执行存储过程后,以下情况是会抛出异常的:
1、obj.ID = dr.IsDBNull(0) ? 0 : dr.GetInt32(0);
2、obj.ID = (dr["ID"]==null)?0:(int)dr["ID"];
3、obj.ID = (dr["ID"]==null)?0:(Int32)dr["ID"];
 
解决办法:
把变量声明为Int64
1、obj.ID = dr.IsDBNull(0) ? 0 : dr.GetInt64(0);
2、obj.ID = (dr["ID"]==null)?0:(Int64)dr["ID"];
或用Convert.ToInt32()、int.Parse()强制转换。
 
以上方法已经验证,不知道还有没有更好的其他办法?有的话请补上。。。 
<think>我们正在设计一个音视频管理系统的数据库表。根据引用内容,我们需要考虑字段设计规范化、权限控制、数据隔离、安全防护、性能优化等。同时,参考建表注意事项,如要有表注释、物理主键自增、基础字段(ID、业务状态等)、页面字段、冗余字段(项目编码、状态、修改人信息、创建人信息等)、字段长度确定等。 音视频管理系统通常需要存储音视频文件的元数据(如标题、描述、时长、格式等)以及文件本身(或文件存储路径)。此外,可能还需要存储转码信息、缩略图、审核状态等。 根据引用[3]中关于文件存储的例子,我们可以考虑使用BLOB类存储小文件(如缩略图),但音视频文件通常较大,不建议直接存储数据库中,而是存储文件路径,文件本身存放在文件存储服务(如对象存储)中。引用[4]提到RAW和LONG RAW类,但Oracle中我们也可以使用BLOB(二进制大对象)来存储二进制数据,不过大文件通常不推荐直接存数据库。 因此,我们设计表时,对于音视频内容,我们只存储文件路径(或URL),而缩略图如果较小,可以考虑用BLOB存储(如TINYBLOB或BLOB),或者同样存储路径。 下面设计一个基本的音视频表(media)的字段: 1. 主键:自增ID,作为物理主键。 2. 基础字段:业务状态(例如:0-未审核,1-已审核,2-禁用等)、单号(如果需要,比如业务流水号)、标题、描述等。 3. 页面字段:用户需要看到的字段,如文件名、文件类(扩展名)、文件大小、时长、分辨率、封面图(缩略图)URL、文件URL、创建时间、更新时间等。 4. 冗余字段:创建人ID、创建人姓名、修改人ID、修改人姓名、创建时间、修改时间(这些字段在多个表中常见,便于追踪)。 5. 其他业务字段:如分类ID、标签、播放次数、点赞数等(根据业务需求)。 注意:根据引用[2],可以确定长度的字段使用char,否则用varchar,并设置合适的长度。 另外,考虑到安全,我们可以存储文件的校验和(如引用[3]中的checksum字段),用于验证文件完整性。 因此,我们可以设计如下表结构: ```sql CREATE TABLE media ( -- 主键 media_id INT AUTO_INCREMENT PRIMARY KEY COMMENT '媒体文件ID', -- 基础字段 title VARCHAR(255) NOT NULL COMMENT '标题', description TEXT COMMENT '描述', status TINYINT NOT NULL DEFAULT 0 COMMENT '状态:0-未审核,1-已审核,2-禁用', -- 文件相关信息 file_name VARCHAR(255) COMMENT '原始文件名', file_size BIGINT COMMENT '文件大小(字节)', file_type VARCHAR(50) COMMENT '文件类(如video/mp4)', duration INT COMMENT '时长(秒)', resolution VARCHAR(20) COMMENT '分辨率(如1920x1080)', file_url VARCHAR(500) NOT NULL COMMENT '文件存储路径(URL)', thumbnail_url VARCHAR(500) COMMENT '缩略图路径(URL)', -- 如果需要直接存储缩略图二进制(如果缩略图很小,比如几KB),可以添加如下字段,但通常不推荐,除非有特殊需求 -- thumbnail BLOB COMMENT '缩略图二进制数据', checksum CHAR(64) COMMENT '文件的SHA-256校验和', -- 冗余字段(创建和修改信息) create_by INT COMMENT '创建人ID', create_by_name VARCHAR(100) COMMENT '创建人姓名', create_time DATETIME NOT NULL COMMENT '创建时间', update_by INT COMMENT '修改人ID', update_by_name VARCHAR(100) COMMENT '修改人姓名', update_time DATETIME COMMENT '修改时间', -- 其他业务字段 category_id INT COMMENT '分类ID', play_count BIGINT DEFAULT 0 COMMENT '播放次数', like_count BIGINT DEFAULT 0 COMMENT '点赞数' ) COMMENT '音视频媒体文件表'; ``` 注意: 1. 我们使用VARCHAR(500)存储URL,因为URL可能较长,但一般不会超过500字符,如果可能更长,可以适当增加或使用TEXT类。 2. checksum字段使用CHAR(64),因为SHA-256校验和是64个十六进制字符,固定长度。 3. 状态字段使用TINYINT,假设状态值在0-127之间。 4. 文件大小使用BIGINT,因为文件可能很大(超过INT的最大值)。 5. 时长(秒)使用INT,一般视频时长不会超过INT最大值(约68年)。 6. 播放次数和点赞数使用BIGINT,避免大热门视频导致计数溢出。 此外,根据引用[1]中的权限控制和数据隔离,我们可能需要关联站点ID(如果系统是多站点的)。例如,添加一个site_id字段,用于标识该音视频属于哪个站点。同时,在权限控制时,可以根据用户角色和站点ID进行数据访问控制。 因此,我们可以添加: site_id INT NOT NULL COMMENT '所属站点ID' 另外,根据业务需求,可能还需要考虑: - 转码信息:如果同一个音视频有多个转码版本,可能需要另外设计转码表。 - 标签:如果支持标签,可能需要一个标签表和关联表。 以上设计是一个基础版本,具体需要根据实际业务需求调整。 相关问题: 1. 如何设计音视频转码信息表? 2. 音视频管理系统中如何实现权限控制? 3. 音视频文件存储方案有哪些?如何选择?</think>### 音视频管理系统数据库表设计指南 #### 核心表结构设计(media 表) ```sql CREATE TABLE media ( -- 主键与基础字段 media_id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT '媒体ID', site_id INT NOT NULL COMMENT '所属站点ID [^1]', title VARCHAR(255) NOT NULL COMMENT '标题', description TEXT COMMENT '描述', file_name VARCHAR(255) NOT NULL COMMENT '原始文件名', -- 媒体属性 duration INT NOT NULL COMMENT '时长(秒)', resolution VARCHAR(20) COMMENT '分辨率(如1920x1080)', file_format VARCHAR(10) COMMENT '文件格式(mp4/mp3/avi)', file_size BIGINT NOT NULL COMMENT '文件大小(字节)', -- 存储路径 file_path VARCHAR(500) NOT NULL COMMENT '存储路径/URL', thumbnail_path VARCHAR(500) COMMENT '缩略图路径', -- 安全与校验 checksum BINARY(32) COMMENT 'SHA-256校验值 [^3]', encryption_key VARCHAR(128) COMMENT '加密密钥', -- 状态管理 status TINYINT DEFAULT 0 COMMENT '状态(0-待审核,1-已发布,2-禁用) [^2]', audit_status TINYINT COMMENT '审核状态', -- 元数据 create_by INT NOT NULL COMMENT '创建人ID', create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', update_by INT COMMENT '修改人ID', update_time DATETIME ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间 [^2]' ) COMMENT '音视频主表'; ``` #### 关键字段说明 1. **核心媒体属性** - `duration`:精确到秒的播放时长 - `resolution`:存储分辨率值(如 4K/1080P) - `file_size`:使用 BIGINT 支持大文件(最大 8EB) - `checksum`:二进制存储 SHA-256 校验值,确保文件完整性[^3] 2. **存储设计** - **文件路径存储**:推荐存储对象存储路径而非直接存 BLOB(大文件影响性能)[^4] - **缩略图分离**:独立存储封面图路径(可考虑 BASE64 小图缓存) 3. **状态管理** 采用规范化状态字段: ```sql status TINYINT DEFAULT 0 COMMENT '0-待审核 1-已发布 2-禁用 3-归档' audit_status TINYINT COMMENT '0-未审 1-通过 2-驳回' ``` 4. **安全字段** - `encryption_key`:用于加密媒体流的密钥 - `site_id`:实现多租户数据隔离[^1] 5. **元数据规范** 遵循审计字段标准: ```sql create_time DATETIME DEFAULT CURRENT_TIMESTAMP update_time DATETIME ON UPDATE CURRENT_TIMESTAMP -- 自动更新时间戳 [^2] ``` #### 扩展表示例(转码信息表) ```sql CREATE TABLE media_transcode ( transcode_id BIGINT AUTO_INCREMENT PRIMARY KEY, media_id BIGINT NOT NULL COMMENT '关联媒体ID', bitrate VARCHAR(20) COMMENT '码率(如2500kbps)', resolution VARCHAR(20) COMMENT '转码分辨率', format VARCHAR(10) COMMENT '输出格式', file_path VARCHAR(500) NOT NULL COMMENT '转码文件路径', transcode_time DATETIME COMMENT '转码完成时间', INDEX idx_media_id (media_id) ) COMMENT '转码版本表'; ``` #### 最佳实践建议 1. **存储策略** - 大于 100MB 的文件使用对象存储(如 S3/MinIO)+ 路径存储 - 小文件缩略图(<5MB)可考虑用 BLOB 存储[^3] 2. **性能优化** ```sql ALTER TABLE media ADD INDEX idx_status (status); ALTER TABLE media ADD INDEX idx_create_time (create_time); ``` 3. **安全设计** - 敏感字段(如 encryption_key)应用 AES 加密存储 - 通过 JWT 站点化认证实现访问控制[^1] 4. **字段注释规范** 所有字段必须包含中文注释(如 `COMMENT '文件大小(字节)'`),便于团队协作[^2] #### 设计依据 1. 文件路径存储替代 BLOB 类,避免数据库膨胀(基于 Oracle RAW 类限制启示)[^4] 2. 状态字段使用 TINYINT 而非字符串,提升查询效率[^2] 3. 校验和字段采用二进制存储,优化校验效率[^3] 4. 站点字段实现多租户数据逻辑隔离[^1] ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值