3 ms·
In #3, SQLAlchemy loses because it's "complex" while JSON is "simple". In #4, SQLAlchemy loses because this time it's "complicated", whereas inlining SQL create
by alexatkeplar 15y ago
In #3, SQLAlchemy loses because it's "complex" while JSON is "simple". In #4, SQLAlchemy loses because this time it's "complicated", whereas inlining SQL create table statements is merely "complex".
Conclusion: for Hunter Blanks, SQLAlchemy can never win.
- dchest 15y ago"The order of examples is not necessarily bad first, good second." http://news.ycombinator.com/item?id=2203101 http://news.ycombinator.com/item?id=2203101
- jobeirne 15y agoIMO, #3 was more about YAGNI[1], i.e. you probably won't need the speed, integrity constraints, relations, etc. delivered by SQL, so keep your data model flexible and lightweight until a shortage of those things is actually getting in your way. I wouldn't be surprised if many people criticizing #3 had no practical experience with NoSQL and the benefits brought by its lack of baggage. [1]: http://en.wikipedia.org/wiki/You_aint_gonna_need_it http://en.wikipedia.org/wiki/You_aint_gonna_need_it
- glassx 15y agoSQLAlchemy is "complex" in both #3 and #4, so it wins in #4.