nev*_*ame 6 mysql database postgresql ruby-on-rails
我正在使用Rails,它不支持数据库特定的操作,如触发器,存储过程和各种约束(不是全部).
我想知道是否应该将数据库逻辑放在应用程序本身中.
因为那时你可以创建比数据库提供的更复杂的逻辑,它也是数据库独立的(我可以从mysql移动到postgresql,反之亦然),如果你把这些东西放在数据库中就不会这样.
这是正确的方法吗？
谢谢
rfu*_*sca 14
(注意:这是Postgres的中心帖子.我有几年的MySQL经验,还有一些Postgres和Oracle.我更喜欢Postgres一个国家里程,但这不是这篇文章的重点.)
这真是一个关于两种思想流派的问题:数据库应该只是一个数据存储还是应该包含应用程序逻辑？两者都有.
恕我直言,在几个DB(特别是Postgres)在DB本身中获得了一些非常非常好的过程语言之前,答案已经变得更加简单了.在此之前,将所有可能的逻辑放在应用程序中是有意义的,因为在基本SQL中完成一些事情必须相当笨拙.
Dave Markle在另一个答案中对触发器提出了一个很好的观点,它们往往对开发人员来说是"神奇的".在途中改变输入可能非常混乱.如果我说UPDATE foo set X=3;但是我去检查foo并且x真的4是因为一些触发器拦截它,它可能会令人困惑.像戴夫一样,我倾向于推广审计功能等的触发器.触发器的另一个问题是性能,他们可以从良好的批处理操作中榨取生命.
存储过程 - 我更加重视.开发人员明确地调用它们并且它们被命名,因此他不应该将它们视为黑盒子.良好的存储过程可以通过减少需要"通过线路发送"的行数来大大提高速度.对于像Postgres这样具有强大PL语言的数据库来说,SP中没有任何东西是不可能的(这并不意味着它应该被完成,但可以).请看一下SimplyCity,了解存储过程如何成为您的朋友.此外,您可以在应用程序代码和PL/python,PL/Perl或PL/Php,PL/Ruby或PL/Java之间共享应用程序逻辑类.我相信Oracle可以用Java做类似的事情 - 它'
如果你计划保持数据库不可知,那么你将会牺牲很多功能,速度和时间.ORM可以使这更容易,但最终在大多数数据库引擎中存在根本区别,这些引擎无法完全抽象出来.
总的来说,您需要测试,测试,测试(使用真实数据)并做出最适合您应用的决策.它通常是性能,未来维护,成本和您必须使用的资源之间的平衡行为. 通常(不是每次)将逻辑移出数据库并进入应用程序会大大降低应用程序的性能.
即使您没有决定将应用程序逻辑放在数据库中 - 花时间真正了解您选择的数据库.从长远来看,它将使您成为一个更好的应用程序开发人员.
我会给出一个可能与其他人都会说的相反的答案.
数据库逻辑属于您可能实现的数据,并且这意味着在数据库中.做其他事情充其量只会要求你在不同的应用程序中重复自己,并且有一个很大的更新问题.在最坏的情况下(这很可能),您将在不同的应用程序中实现不一致的数据库逻辑.
你需要分离出什么是"数据库逻辑"和什么是"应用程序逻辑".我的正常例子是通过"FullName"为客户定义组织的含义.想象一下,您在应用程序中编写了将名字和姓氏组合成全名字段的代码.稍后,您将添加中间首字母(或决定包含已存在的中间初始列)作为全名的一部分.
如果在视图或存储过程中实现了全名逻辑,则只需进行一次更改即可跨所有应用程序(包括您没有源代码的第三方应用程序)强制执行新定义.
在诸如Ruby之类的情况下,问题有所缓解,其中所有数据访问都是通过共享ORM层完成的,您可以在其中放置将使用相同语言编写的所有应用程序使用的逻辑.然而,在我的情况下,我很少在只有一种语言或产品用于公司数据库编程的情况下工作.
如果您已经在使用Ruby on Rails,那么您已经致力于使用固定意见的软件.无论是对还是错,Rails对此问题的看法是逻辑在Rails应用程序中.它甚至可以通过ActiveRecord及其关联来强制执行参照完整性,尽管如果您希望通过向表添加约束来强制执行此操作.很多Rails开发人员都不会因为无知或选择而烦恼.