使用Sqlalchemy和红移实质的视图是个好主意吗？
我正在研究一个带有烧瓶的新项目，该项目将大量从红移数据库中读取，尤其是从物有的视图中读取。我是烧瓶/sqlachemy/orms的新手。我想使用烧瓶-Sqlalchemy用ORM抽象数据库层。当我阅读文档时，我注意到SQL Alchemy需要基础数据库源具有主键。但是，我担心在没有任何主要钥匙的情况下实现的视图会引起问题。
我发现有一些解决方法可以将某些列指定为主要键，但我不确定当我对实体视图执行连接时，这是否会导致问题。我敢肯定，这也可能会有解决方法，但是当我的大多数操作都是从物有的视图中使用大量的读取操作时，我认为是否将ORM与解决方法是个好主意。因此，我有两个问题
1）
是否有可能将Sqlalchemy与红移实现的视图一起使用（我无法在此上找到足够的资源）
2），
如果可能的话，使用SQLalchemy是个好主意，还是我应该使用自己的PostgreSQL Pooling逻辑坚持使用RAW SQL查询？
谢谢。
PS：我没有红移中的主要键，但是我有区域/排序键。
我使用的参考/链接：
I am working on a new project with Flask that will heavily read from a redshift database and particularly from materialized views. I'm fairly new to Flask/SQLAchemy/ORMs. I want to abstract the database layer with ORM by using Flask-SQLAlchemy. When i was reading the documents, i noticed SQL Alchemy requires underlying database source to have a primary key. However, i am worried that having materialized view without any primary key will cause a problem.
I found out that there are some workarounds to specify some columns as primary key even when they are not but i'm not sure if that will cause an issue when i perform a join on materialized views. I am sure there might be a workaround for this one as well but i'm thinking if using ORM with workarounds is actually a good idea when most of my operations will be heavy read operations from materialized views. So i have two questions
1)
Is it possible to use SQLAlchemy with Redshift Materialized Views (I wasn't able to find enough resources on this one)
2)
If possible, is it a good idea to use SQLAlchemy or should I stick to raw sql queries with my own logic of postgresql pooling?
Thank you.
P.S: I have no primary keys in redshift but i have dist/sort keys.
References/Links I used:
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这不是真的。 您可以使用合成主键。我正在将它们与没有单列主要键的TimeScaledB高hapersables一起使用。
Sqlalchemy不在乎基础数据库，因为长SQL Wire协议及其风味是兼容的（PostgreSQL，MySQL，Ett。 ）
使用SQLalchemy提高代码的可读性，然后长期降低维护成本。
This is not true. You can use synthetic primary keys. I am using them with TimescaleDB hypertables that do not have single-column primary keys.
SQLAlchemy does not care about the underlying database, as long SQL wire protocol and its flavour is compatible (PostgreSQL, MySQL, etc.)
Using SQLAlchemy improves the readability your code and then reduces maintenance costs in long term.