Nik*_*nko 4 sql oop orm stored-procedures
我继承了一个严格使用存储过程来完成其工作的Web应用程序.我喜欢让前端开发人员无法破坏数据库的方法,但我已经厌倦了用纯SQL编写SP调用并希望有更好的东西.虽然我一直在寻找一个体面的ORM(在这种情况下用于Perl,但这与问题无关)并支持存储过程,但我意识到ORM可能与SP直接矛盾.
我的想法是,SP就像名字已经告诉我们的那样,程序,即程序Pascal式编程的代表,事实上,一个Web应用程序看起来与SQL-Server端的Pascal完全一样 - 很多功能,没有真正的命名空间.与此相反,我们试图完成大部分编程OOP风格(或功能,这是另一个主题),因此实际上,过程SP并不适合干净的对象层次结构.同时,关系逻辑可以干净地(通过ORM)转换为对象,但不是程序,这可能是大多数ORM不能很好地支持SP的原因(但我不是该领域的专家).在某种意义上,SP 是 ORM.
所以这两个问题是:
"我认为在运行ORM时我们最好使用普通表吗？"
是.
RDBMS应该专注于持久存储,仅此而已.
如果你这样做,你会发现你可以 - 轻松 - 用你的OO语言建立一个访问层.所有"前端"开发人员都必须使用访问层,不能破坏数据库.
"面向对象的存储过程？"
Oracle有一些类似于OO的PL/SQL功能.
不要浪费任何时间.专注于持久性(在RDBMS中)和应用程序处理(不在RDBMS中)之间的清晰分离.
许多人会向你发送仇恨邮件,说"供应商将所有这些功能放在那里,这意味着你应该使用它们"和"存储过程有什么问题？" 并且"一个优秀的DBA比一个充满前端开发人员的房间更好"等.
我不知道为什么人们声称存储过程"更好",但许多系统最终到达了存储过程和触发器变得如此繁重以至于必须重写的墙.
我从未见过有人抱怨他们在数据库外面有太多的应用程序软件.
继续按照您的想法 - 使用ORM - 避免存储过程.