使用 Elixir 有什么好处
...与声明式 sqlalchemy 相比？
... vs declarative sqlalchemy ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
...与声明式 sqlalchemy 相比？
... vs declarative sqlalchemy ?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（3）
我在此列出了实际（技术）差异/优点elixir 与 sqlalchmey，但我不知道我的说法是否正确，因为我对 sqlalchemy 的了解非常有限（我使用了 elixir 和 sqla 的一小部分）。
如果答案显示 sqla 中的代码示例和 Elixir 中的等效代码以显示差异，那么这将是非常明智的证明，因为在 stackoverflow 中回答了一些比较问题（例如，我想到了 mako 与 jinja2）
无论如何，这是我的列表，我如果有人纠正我（纠正我对 sqlalchemy 的假设），我将非常感激
Elixir 实现了 Active Record 模式，并且旨在替换 ActiveMapper SQLAlchemy 扩展。 （过时：sqlalchemy 赶上了？）
关系黑白模型很清晰（呃）：OneToMany、ManyToOne、ManyToMany 和 OneToOne 比 sqla 的关系更清晰。一目了然，您可以看到模型之间的关系。
继承性比 sqlalchemys 更方便。由于您是从类派生的，因此它也更加明显。在sqla 中，您必须调整with_polymorphisme 和polymorphic_on 属性。
继承性：在 Elixir 中，表、列和外键是自动创建的，但在 sqlalchemy 中则不然。 （100% 正确吗？）
Elixir 自动为所有表创建一个 ID 列（如果没有声明其他primary_key）
在 Elixir 中，大多数时候，您不必指定在你的关系中回溯。在 sqla 中，您总是必须 (?)
Elixir 有一个版本控制扩展（sql 没有？）
Elixir 有一个关联扩展创建 ManyToMany 关系并提供很好的 select_by_XXX 方法，其中 XXX 是“关联”类的名称。 Sqla 没有这种扩展（？）
继承关系在 Elixir 中是透明完成的。在sqla中，不是，你必须这样做： http: //www.sqlalchemy.org/docs/reference/ext/declarative.html#mixing-...)
I have started a list here on practical (technical) differences / advantages of elixir vs. sqlalchmey, but I don't know if my claims are right because my knowledge about sqlalchemy is very restricted (I use a very small portion of elixir and sqla).
It would be very proof-wise that answers show a code example in sqla and the equivalent in elixir to show differences, as some comparison questions were answered here in stackoverflow (I think of mako vs jinja2 for example)
Anyway, here's my list, I would really appreciate if people correct me (correct my assumptions on sqlalchemy)
Elixir implements the Active Record Pattern and is intended to replace the ActiveMapper SQLAlchemy extension. (out dated : sqlalchemy caught up ?)
Relations b/w models are clear(er) : OneToMany, ManyToOne, ManyToMany and OneToOne is clearer than sqla's relation. At a glance, you can see the relations b/w your models.
Inhertience is more convinient than in sqlalchemys. It is also more visible since you derive from classes. In sqla, you'll have to tweak with_polymorphisme and polymorphic_on attributes.
Inhertience : in elixir, tables, columns, and foreign keys are created automatically, but not in sqlalchemy. (is it 100% true ?)
Elixir automatically creates an ID column for all tables (if no other primary_key is declared)
Elixir creates FK for relations automatically, sql does not (?)
In elixir, most of times, you don't have to specify the backref in you relations. In sqla, you always have to (?)
Elixir has a versionning extension (sql haven't ?)
Elixir has an associable extension that creates ManyToMany relations and provides nice select_by_XXX methods where XXX is the name of the "associated" class. Sqla dosen't have this kind of extension (?)
Inheriting relations is done transparently in Elixir. In sqla, it's not, you have to do this : http://www.sqlalchemy.org/docs/reference/ext/declarative.html#mixing-...)
你可以说 Elixir 的诞生是因为 SQLAlchemy 对于某些人来说声明性不够。
来自 Elixir 网站：
You could say that Elixir has been made because SQLAlchemy is not declarative enough for some people.
From the Elixir website:
我发现 Elixir 语法在从头开始为给定应用程序构建数据库时非常有用，并且所有内容都已事先弄清楚。
当我在遗留数据库（以及其他类似的逻辑上不可变的模式）上使用 SQLAlchemy 时，我获得了最好的运气。特别有用的是插件 SQLSoup，用于只读一次性提取数据，为将其迁移到其他地方做准备。
YMMV，但 Elixir 并不是真正为适应旧模式而设计的——而 SQLAlchemy 对于大多数中小型项目来说是多余的（当然在我看来）。
The Elixir syntax is something I find useful when building a database for a given app from scratch and everything is all figured out beforehand.
I have had my best luck with SQLAlchemy when using it on legacy databases (and on other similarly logistically immutable schemas). Particularly useful is the plugin SQLSoup, for read-only one-time extractions of data in preparation for migrating it elsewhere.
YMMV but Elixir isn't really designed to adapt to older schemas -- and SQLAlchemy proper is overkill for most small- to mid-size projects (in my opinion of course).