mysql、sqlite 和 pgsql 之间的语法差异
我正在使用 PDO 创建一个小型的 activerecord 库,并计划支持 MySQL、Sqlite 和 PgSQL。
我的问题是如何确保查询字符串适用于所有适配器?主要是带有一些连接等的 CRUD 语句。是否有一个我可以遵循的适用于所有这些的标准?
谢谢 / Tobias
编辑:感谢您的所有回答,但我的问题更多是关于它们之间的 SQL“语法”差异。
I'm creating a tiny activerecord library using PDO and I'm planning to support MySQL, Sqlite and PgSQL.
My question is how I can be sure that the query string works with all adapters? There will mostly be CRUD statements with some joins etc. Is there a standard I can follow that works for all of these?
Thanks
/ Tobias
EDIT: Thanks for all your answers but my question was more about the SQL 'syntax' differences between them.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
如果您想编写自己的数据库层,我建议您:
注意:通过支持这些截然不同的 RDBM,您可以将数据库降级为数据存储。请记住,SQLite 的功能非常有限。它没有从数字/字符串保存的本机数据类型。例如,它缺少日期处理和间隔等等。所有三个数据库都支持事务,当在数据库外部维护完整性时,事务对于数据完整性至关重要。
编辑:删除了 MySQL 触发器的提及,该触发器可用于 5.0。
If you want to write your own DB layer, I'd suggest you:
Note: By supporting these vastly different RDBMs, you're demoting the database to just a data store. Keep in mind that SQLite is very limited. It does not have native data types save from number/string. E.g. it's missing date handling and intervals, and so on. All three databases support transactions, which are essential for data integrity when the integrity is maintained outside the DB.
Edit: Removed mention of MySQL triggers, which are availabe for 5.0.
这里对 zend_db_adapter 有一个简单的介绍 - 我想你想要类似的东西(我发布这个只是作为一个例子,看看其他人如何解决你遇到的问题)
Here you have a simple introduction to zend_db_adapter - i think you want something similar (I posted this just as a example to see how others resolve the problem you have)
对于此类问题,我的选择是 ADOdb。虽然我从未真正将它与 PostgreSQL 一起使用过,但它只是让我在一个恰好与 MySQL 一起诞生的项目中保持理智,然后迁移到 SQL Server、SQLite,然后又迁移回 SQL Server。
My choice for this kind of issues would be ADOdb. While I never actually used it with PostgreSQL, it just saved my sanity in a project that happened to be born with MySQL and then migrated to SQL Server, to SQLite and back to SQL Server.