Sometimes #postgresql feels like the #emacs of #databases. It has so many crazy features and yet I've never had comfortable muscle memory in it, so it always takes me longer to do about anything vs some flavor of #mysql (or #vim, depending on which tract you followed to get here).
any #python reading recommendations to optimize memory use of a dict containing lists which in turn contain lots of small dicts? once build up they can be read-only.
In memory #sqlite is also a good option. I like sqlite because there are great tools like #SQLAlchemy which allows you to have #ORM features, but if it is simple I would just go with the built-in libraries to improve performance.
I also like sqlite with #Docker, as I have the simplicity of a sqlite database, but I can easily share it with containers with mounts and persist the data during development and production.
#VScode also has greay extensions for viewing sqlite databases, making it a glorified csv with advanced query capabilities.
ORMs can be helpful for rapid development, but as projects grow and evolve, they can become a double-edged sword. Dependencies, #performance bottlenecks, and loss of control over #SQL optimizations can hinder mature projects. Striking the right balance between abstraction and direct #database interaction is crucial.
@MarcinW while ORMs may offer raw query capabilities and query previews, concerns about performance bottlenecks and loss of control over #SQL optimizations can still arise. the statement holds true as managing complex projects without an #ORM can often be simpler than with one.
to address your skillset point - why would you want to limit your hires by requesting ORM+SQL knowledge when you can only ask for SQL?
What is your favorite #Python#ORM for #SQL and #SQLite? I am currently looking for an ORM judt to sinplify my implementation.
I am considering going for SQLite because the writes and reads are low, and the total size will also be a few 100 records, but I want the strengths of SQL. Also, I am running it in #Docker, so it simplifies the deployment.
I am aware of the limitations, but I am far below them. I want to project to be easily deployable by others and then the usage will also be low enough for it to suffice.
#Peewee feels a lot like the web-development #ORM that you get for #React and #JS, but I like #SQLAlchemy, the docs also seem good.
SQLAlchemy is the most popular #Python#ORM and has a great support for async/await and type annotations. The documentation is quite messy and overwhelming as soon as you need to go beyond the tutorial, though, and there are too many ways to do the same thing.
Peewee is much easier and smaller but there is no support for async/await and typing and never will be because the author doesn't like it.
I prefer to use something more popular, that the support is better. The docs of #SQLAlchemy are a bit odd. I found myself getting stuck after the tutorial, like you said. It seems 2.0 documentation isn't the best with the new declarative style, but I found some other resources, and I am diving into code I found on #Github to see how others did it.
#Peewee is cool, but the names like that always turn me off. I need serious names for libraries I use, I don't know. But I can see that it had great influence from modern #JS#ORM styles, so it might be better for people coming from that.
The biggest illusion about ORMs is the expectation that they require no SQL knowledge. In due time, you'll have to troubleshoot your ORM code at SQL level.
ORMs help bridging the object/relational gap. But you have to know both sides to successfully use this bridge.
So learn SQL first, then pick an ORM, a SQL builder, code generator, raw SQL, or whatever and write great DB-centric apps. But learn SQL first.