Jef*_*ron 2 string nhibernate orm primary-key
我们有一个使用字符串作为主键的遗留数据库.我想在遗留数据库之上实现对象,以更好地实现某些业务逻辑并为用户提供更多功能.
我已经阅读过在桌面上使用字符串作为主键的地方很糟糕.我想知道为什么会这样？是因为区分大小写的问题吗？字符集？
...为什么NHibernate特别糟糕？
...并跟进...如果字符串确实产生了错误的主键,用int或GUID等替换数据库中的主键是否值得？(我们只涉及约25-30个表)
小智 5
好的,我会抓住这个.我将给出几个快速的注意事项 - 我不是数据库方面的专家,我的经验是使用Hibernate(Java)而不是NHibernate,但是这里有.
我认为主键作为字符串的问题与用于在数据库中表示它们的SQL数据类型有关.由于在插入,查询等时始终使用主键,因此数据库引擎必须花费大量时间来比较主键.如果你使用数字,这些只是存储为字节,计算机真的很擅长快速做事.一旦开始使用字符串,这些操作(主要是比较)的成本就会显着上升.即使数据库引擎使用非常简洁的策略来比较密钥,将字节比较为字节而不是字符串仍然总是更快.
然而,在现代硬件上,这已经变得比以前少得多,并且对于索引,问题几乎消失了.
我不确定为什么这在Hibernate(和NHibernate)中真的很糟糕,但根据我的经验,因为我的应用程序有一个复杂的对象图,它经常引用其他持久化对象,通常作为列表或集合,引用都是使用另一个对象的ID存储的,并且由于我用于级联保存,提取等的规则,这将意味着主键一直被使用.Hibernate - 我非常喜欢 - 倾向于完全按照它所说的去做,有时人们(特别是我!)告诉它做一些非常愚蠢的事情.因此,即使看似简单的更新或查询最终也会产生相当复杂的SQL.
所以 - 总而言之 - 作为主键的字符串很糟糕,因为对它们进行简单操作的成本并且使用Hibernate可能会放大这一点.但在实践中,现代数据库引擎有很多简洁的策略来确保性能不会太差.(Postgres - 可能是其他人 - 默认情况下为主键创建索引)
为了您的跟进 - 您应该更换钥匙吗？那么,这取决于您的应用程序的性能.如果性能至关重要,那么对于大批量和非常密集的应用来说,这可能是一个好主意,否则可能会带来最小的好处,而不得不花时间改变所有表格.您可以期望获得更好的结果,改进您使用NHibernate的策略(即获取策略以及何时进行级联保存等).
| 归档时间： |
|
| 查看次数： |
1806 次 |
| 最近记录： |