不区分大小写,关键字、用户、密码 、字段名 、表名、序列名 、触发器名等是不区分的,我们平时进入都是大小写随便输入的表名,字段名,关键字大小写忽略表名,字段名不能使用关键字,表名,字段名不可以使用数字开头,中间不能出现特殊符号表名,字段名长度不能超过30个字符表名,字段名定义需要有含义。
具体字段值区分大小写。而scott是给初学者学习的用户,学习者可以用Scott登录系统,注意scott用户登录后,就可以使用Oracle提供的数据库和数据表,这些都是oracle提供。
扩展资料:
逻辑结构
它由至少一个表空间和数据库模式对象组成。这里,模式是对象的集合,而模式对象是直接引用数据库数据的逻辑结构。模式对象包括这样一些结构:表、视图、序列、存储过程、同义词、索引、簇和数据库链等。逻辑存储结构包括表空间、段和范围,用于描述怎样使用数据库的物理空间。
总之,逻辑结构由逻辑存储结构(表空间,段,范围,块)和逻辑数据结构(表、视图、序列、存储过程、同义词、索引、簇和数据库链等)组成,而其中的模式对象(逻辑数据结构)和关系形成了数据库的关系设计。
建议你看看数据库相关的教程,首先 char 和varchar 两个是不一样的 char(20) 是定长字符串,varchar是变长字符串,int 、double 等都有自己的取值范围,定义字段要看自己需要存储的数据大小来设计
报这个错误 是因为你插入的字符串长度超过了你定义的字符串长度\x0d\就是你那个nchar 你上面定义了3个这样的类型 \x0d\要一个个的排除了 看你的表files 对应的字段哪个字段比你传入的字符串长度短就是了\x0d\还有就是变量的赋值也不能超过变量定义的长度 \x0d\\x0d\总结一下,有两原因:\x0d\一、变量的赋值不能超过变量定义的长度\x0d\二、表files 对应的字段的长度要和变量传入的字符串长度相同
如果你的SQL是SQL2000varchar最长长度可以是8000,
如果是SQL2005以上版本可以支持varchar(max),最长可达2G的字段容量数据
你可以试试,也许你的1024还是不够。
本人这个领域工作10多年,没有听说过数据库字段最好要设置成2的N次方这种说法。相信现在的数据库系统和CPU缓存机制早就做了优化,上层设计数据模型的时候根本无须考虑这些,尽管根据业务需要来定义字段长度吧。
varchar是可变字符,varchar(2000)即可,不会浪费空间。
楼主为何要将历史记录存在access中呢?若您后台有sql server支持,建议您历史记录也存放在sql中,access的性能及对sql的语言支持都远不如 MSSQL。
VARCHAR限制了字符串的长度不能超过255个字符---哦,忘记了,这个可能access有此限制,sql可以的,最大varchar(8000)。
varchar(100)中的100并不多余,在未存储数据时用于占位,系统会用于预先计划分配空间,但直到真正存储数据时才确实分配存储空间。
个人看法:
1占用空间上varchar(100)和varchar(2000)没什么区别。
2但varchar(100)会效率较低,因为按你说的该字段会5-2000,若大于100,则您每次固定写入100会需要多次写 *** 作,众所周知写 *** 作是比较耗时的。
3查询性能方面,跟您这儿怎么存没太大关系,重要的还是常见的数据库查询优化,如索引、条件等等
对这个问题,我引用一下CSDN上的说法:
一。数据行结构
char(n): 系统分配n个字节给此字段,不管字段实际长度(后边用空格补齐)
varchar(n): 假设表中有M个varchar(或者nvarchar)类型的字段
先分配两个字节(用来表示M)
再分配2M个字节(表示各变长行的偏移)
此后字段值有多长,就分配多长
二。varchar(n)一定比char(n)节省空间么
不一定。
我见过这样的设计: varchar(3)
就算此字段为空,也还是比char(3)多用一个字节。
还有这样的设计: user_ip varchar(16)
对于这种数据长度变化不大的字段,用varchar只能浪费空间
结论: varchar适用于数据值长度不太短,且长度变化较大的字段
三。char(n)一定比varchar(n)速度快么
不一定
计算varchar的偏移是会花去一些cpu时间,但性能瓶颈不在此,在io
db的io单位是数据页(8192字节)(一页存有多个数据行,数据行不能跨页。当然image,text等例外) 因此一页中行越多,性能越好
另外,关于char和varchar的性能比较,
请参见该实验:
>
以上就是关于数据库的字段区分大小写吗全部的内容,包括:数据库的字段区分大小写吗、在数据库中创建表时创建字段,往往要给字段类型和大小,那么我们要怎么给例如:、将截断字符串或二进制数据等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)