id (int) | Serialized Object (blob) 1 10010110110
我可以看到这么多问题;数据冗余,必须单独跟踪id,必须将整个表拉入内存以搜索任何内容,**如果我想在Java代码中更改我的模型,我将无法再反序列化存储在数据库进入该模型.
要么我永远坚持这个模型,要么我必须做一些其他非常难看的东西来改变我的模型.**这整件事对我来说似乎是不好的形式.我是否有理由不同意我的教授？这样做有什么好处,我没有想到？如果我是对的,我应该向我的教授说些什么吗？他正在向我全班讲道,甚至说他已经建立了这样的项目.第二种意见会很棒.
该课程名为软件设计.
我的教授没有说这是最好的方法,但他确实说这是定义关系表的合法替代方法.
该模型在任何方面都不是动态的.
解决方法
>粗体部分是错误的.您可以轻松扩展已经序列化的对象以添加新字段并实现与旧对象的完全二进制兼容性.您也可以简单地创建新类而不是更改原始类.
你与教授的讨论应该关注不同场景中“关系”与“键值存储”的利弊,而不是抽象的“更好”.或者您也可以讨论圣诞节是否优于感恩节.
– 阅读其他答案后的编辑.
其中一个答案就是说“很难想象一个优势胜过缺点的案例”.
因为整个讨论必须是关于具体问题(否则我们甚至不能定义“更好”和“更糟糕”),让我举一个具体的例子.它已完全弥补,但我试图充实尽可能多的细节.
想象一下,你有一个在线游戏网站,有一个数据库,存储不同在线游戏中玩家的统计数据(在浏览器中播放,用GWT编写并交叉编译为javascript).有些游戏是战略性的,有些是动作游戏,有些是平台游戏.数据库是关系型的,存储玩家和游戏历史以及得分.
有一天你会得到一个额外的要求：让玩家在游戏过程中将游戏状态保存到云中,这样他们就可以在同一时间重启游戏.毋庸置疑,存储这种临时状态的唯一理由是重返游戏,国家本身永远不会被反省.
现在您有两个基本选择：
>由于游戏是用Java编写的,因此您可以非常轻松地获取模型,将其发送到服务器,在一行代码中将其序列化并存储为blob.该表将被称为“saved_games”,它将具有播放器的外键等等.从数据库的角度来看,“保存游戏”是一个不透明的,不可分割的blob.
>您可以为100个游戏中的每一个创建单独的关系模型
(这将是每场数十桌).例如,对于pacman来说,你必须有一张桌子,存放所有未吃的弹丸,奖励,位置和鬼魂当前状态的位置.如果有人某天修改游戏,即使是稍微修改游戏,你也必须更新关系模型.此外,对于每种类型的游戏,您都必须实现一个逻辑,将Java模型编写到数据库中,然后将其读回.
Justin Cave的答案说,你应该选择第二种选择.我认为这将是一个巨大的错误.
此外,我有一种预感,Justin Cave认为上面提到的是“边缘”或“罕见”的情况.我相信,除非他能提供某种硬数据(基于世界上所有IT项目的代表性抽样,而不仅仅是美国的企业应用程序),我会认为这种观点是投影的经典案例.偏压.
实际上,关系数据库中序列化Java对象的问题比看起来要深刻得多.它涉及1NF的核心,即属性的域名是什么？如果你对这个主题真的很感兴趣,那么C. J. Date在他的数据库日期：2000-2006的文章中有一篇很棒的文章.
