[请益] DB设计上为何不要都开NVARCHAR2(4000)

楼主: returnbool (Lasa)   2014-08-15 16:41:11
各位前辈,目前同仁们在讨论一个问题,主要是关于数据库设计方面,
根据Oracle的说明 NVARCHAR2 为长度可变动的字段格式,
有个问题是,假设设计身分证的字段,
当我把字段设定成ID_NUM NVARCHAR2(10) 与 ID_NUM NVARCHAR2(4000)
就前提来看,只要我都只存10个字符,那个所占用的空间"应该"是一样的,
如果说站在这个角度上,我将所有的字段都设定成 NVARCHAR2(4000),
那么有没有非常显在的缺点 ?
目前是想像的到的
1. 无法从DB Schema看出长度限制
2. table fragmentation
3. 效能问题
还有其他潜在的问题吗 ? 若是都把字段设成NVARCHAR2(4000)的话呢 ?
作者: uranusjr (←這人是超級笨蛋)   2014-08-15 16:54:00
这要看实作, 不过一般而言就是 good practice 而已
作者: DrTech (竹科管理处网军研发人员)   2014-08-15 17:18:00
对我来说,最大的缺点就是被人看到,会被冠上不专业对我来说"看起来"很专业蛮重要的。
作者: LINGZ (肥兔小钦)   2014-08-15 18:03:00
max row size限制.
作者: alan3100 (BOSS)   2014-08-15 18:57:00
等你建index就知道了
作者: sabreur (无奈)   2014-08-15 19:10:00
主管看到会火了你吧..
作者: klandor (飞行翼)   2014-08-15 19:40:00
固定长度的话 用NCHAR效能会比较好吧
作者: alan3100 (BOSS)   2014-08-15 20:43:00
不是看起来专不专业的问题 感觉没问题是碰的太浅
作者: robler (章鱼丸)   2014-08-15 21:21:00
满讨厌那种光是说别人不懂 或是 说别人不专业 太弱但是又不肯说出来问题到底是什么 是哪里的问题光是在那边酸到底是有什么意义?
作者: alan3100 (BOSS)   2014-08-15 21:55:00
前面不就给key了吗? 倒是你啥都没讲就想战不然我改一下好了, 我道歉 一切只为了看起来很专业 end
作者: kunchung   2014-08-15 22:00:00
配置空间没差,但client alocate memory没那么聪明fetch 资料时不会去算每一个row的实际大小变动长度开大不会影响储存空间是对的
作者: GoalBased (Artificail Intelligence)   2014-08-15 23:07:00
今天有人在你身分证字段输入2000个字你会爽吗?
作者: zo4j4 (happiness)   2014-08-16 00:00:00
推kunchung一样不喜欢alan3100态度
作者: TllDA (踢打)   2014-08-16 05:36:00
client allocate memory是什么意思? client又不知道DB设定
作者: osnq (又可以挂bbs了)   2014-08-16 06:06:00
同Tiida 的疑问
作者: thanksyou (谢谢你)   2014-08-16 09:30:00
推一堆文,结果没人知道确切的答案....
作者: LoveBoat (ronin)   2014-08-16 09:42:00
cache efficiency, sorting speed
作者: odbc (odbc)   2014-08-16 11:40:00
好问题,所以为了方便,我都是nvarchar(10)/(50)/(200)开字段,不然要事先知道所以资料的max lengh 太累了我也想说都开nvarchar(50)/(200)真的效能有差吗?至少书上说储存空间(空间配置)是没差的
作者: fsz570 (570)   2014-08-16 11:47:00
http://goo.gl/kv4G08缺点还蛮多的,不过我觉得对于"设计"的态度问题才严重设计 table 时对于你要存进数据库的资料要有概念不应该只是数据库放的进去,程式会跑就好实务上的经验只有 comment 这种字段会这样开因为连 User 也不确定实际使用时会需要多大不过顶多也开个 1024 就够了
作者: DrTech (竹科管理处网军研发人员)   2014-08-16 12:07:00
很多人都知道一堆小问题吧,但都不是大问题。效能、安全、空间、索引这些都会有小问题,但这些问题相对来说,都不如在客户面前或上司面前黑掉。数据库全部这样开,影响最大的真的是自己的专业形象与观感
作者: andymai (人生只有一次)   2014-08-16 13:02:00
其实最明显的问题是:为什么你的主管会让你这样玩???
作者: knives   2014-08-16 13:08:00
明明就是存身分证,你开到四千是想怎样
作者: Himetsuki (琉璃雪月.咲夜)   2014-08-16 13:57:00
技术面是没有问题、硬件的性能也能支撑这个设计可是ID用来存身分证字号的字段就有个资和格式的考虑了限定10个字符的字段如果塞了不是10个字符的值又没检查不就成了系统里的潜在漏洞?
作者: Blueshiva (龙野南云)   2014-08-16 21:16:00
为什么身分证字号要可以存超过10个字符?很简单啊,你限定10个,然后有个外国人来挂号,没台湾身分证怎么办?填护照号码,超过10个字怎么办?切头切尾,哪天又来另一个外国人护照号码切完之后重复怎么办?主管:当初是谁乱规划DB的?都没想清楚?每个人都这种公务员心态怎么做事啊!
作者: KiroKu ( who)   2014-08-16 21:19:00
差别就是nvarchar(10)存不到4000的char 如果前端没挡insert data的时候可能会报错
作者: On1earth (小浅)   2014-08-16 23:40:00
就像有人把db root帐号给web application使用,要说有什么影响吗?其实也没有,只要不要遇到意外就好了
作者: Lordaeron (Terry)   2014-08-17 18:47:00
原来有护照号码长度是4000的,见识到了.哪人名/电话/地址/email,也可以用相同的理由囉.
作者: nfsong (圖書館我來了)   2014-08-18 21:43:00
我认为有差 数据库够大够多 有相似的字段 在coding就需要ID 有很多种 假设统编 身分证 外国人代码 还有相关的话只要有4 5种类似的延伸 coding就会很头痛y尤其是 因为限制不能判断检核 资料就真的会爆加上甲方 如果 要debug 要申请手续一堆的话
作者: abola921 (南港金城武)   2014-08-18 21:47:00
如果是内部用的系统的话,玩玩不要玩坏了其实没差
作者: nfsong (圖書館我來了)   2014-08-18 21:47:00
来个10次 在这种问题上 大概就不用做了
作者: nfsong (圖書館我來了)   2014-08-18 21:48:00
因为 如果是自己开的当然自己知道 实际上是SD开的假设SD 都开这种 大概会准备找下一嘉公司吧对了 解bug 要算时间的 有的一小时1万.... 何必增加超过罚钱 何必增加自己难度 有时候是维护需求500万笔以上 50个字段 还join来join去资料错误 就真的很难debug 超过罚钱都只能找借口拜托做假资料时也会打错 导致debug 完全看不出来哪里有问题
作者: alan3100 (BOSS)   2014-08-19 22:22:00
下一篇讲一嘴神系统就射后不理, 这一系列看起来也冷了做最后补充,不改oracle设定全开4000 index大概只能1字段如果你的系统连index都用不到就别再扯看起来很专业
作者: shyart (ShyArt)   2014-08-23 09:18:00
如果是不用程式存取的话就没问题 要用程式的话 测试时 可能会要求测试到最大可能值 这时你就知道你的想法没错但只是给自己找麻烦吧

Links booklink

Contact Us: admin [ a t ] ucptt.com