※ 引述《returnbool (lasa)》之铭言：
: 各位前辈，目前同仁们在讨论一个问题，主要是关于数据库设计方面，
: 根据Oracle的说明 NVARCHAR2 为长度可变动的字段格式，
: 有个问题是，假设设计身分证的字段，
: 当我把字段设定成ID_NUM NVARCHAR2(10) 与 ID_NUM NVARCHAR2(4000)
: 就前提来看，只要我都只存10个字符，那个所占用的空间"应该"是一样的，
: 如果说站在这个角度上，我将所有的字段都设定成 NVARCHAR2(4000)，
: 那么有没有非常显在的缺点 ?
: 目前是想像的到的
: 1. 无法从DB Schema看出长度限制
: 2. table fragmentation
: 3. 效能问题
: 还有其他潜在的问题吗 ? 若是都把字段设成NVARCHAR2(4000)的话呢 ?
问题主要不在DB 哪一边, 问题主要在CLIENT 这一边, 和网络这一边.
你就是用伟大的ORM 来写CLIENT, 但你从你的TABLE SCHEMA
, 将无法准确得知一笔资料最多占多少资源. 从而无法好好的
了解你的程式的限制. 再来, 网络哪一段, 也有同样的问题.
你将答不出任何频宽的需求.
当然, 也会像有人说的, 以上都是小问题. 毕境占多少资源问题, OMM 就加大MEMORY
加大了变慢, 就加CPU, 当掉就就要USER 重开囉.
而频宽问题, 不够就加大囉, 100MB, 不够就1GB, 交换机,ROUTER 全都换,
也没多少钱.
程式怎么规画, 怎么写, USER 买不买单就好.

我个人是从来没看过有 ORM 需要知道这个的; 动态字串allocation 不是基本的吗？

ya 所以NoSQL就是潮 grid就是潮

基本啊,所以台湾人写的JAVA是无法7X24. 玩具是没问题的当你连自已的程式的反应都不知时,这要算PROGRAMMER?

资料限制及验证应该要从文件知道吧? XD

咦,文件呢,连IBM/ORACLE 等厂出的文件都没100%,台湾?再来,文件跟你说10,TABLE 是4000,你写程式的,会敢开10?

微软系的Linq to xxx 可都是会用资料形态,长度 产生 codej 系也有靠数据库资料形态长度产code的工具，然后一次就把整个基本资料传递架构长好,还包前端js验证。要是碰上这种一律开nvarchar 4000的状况，真的不用搞软件工程了