If you're using Django, then there isn't really an alternative, as it's really a key selling point of Django.
Some people recommend SQLAlchemy, but I dislike that even more for it's over-engineered complexity. Peewee [1] shows some good potential, but I haven't tried it for myself yet. As for why I dislike the Django ORM, many of the technical reasons are already explained (in detail) in that thread [2] I mentioned before, but a lot of it comes down to personal taste and opinion of what matters most about an ORM etc. Cal [1] https://github.com/coleifer/peewee [2] https://news.ycombinator.com/item?id=4076834 On Wed, Dec 10, 2014 at 7:17 PM, Artie <giliardi.a...@gmail.com> wrote: > Can you please advise why actually you hate Django ORM and what should be > considered instead of it? > > суббота, 6 декабря 2014 г., 23:18:06 UTC+2 пользователь Cal Leeming > написал: >> >> Hi Artie, >> >> First, I would strongly recommend reading some of the work by David >> Mytton at Server Density, he and his team have been using MongoDB >> extensively for many years and they have shared a lot of their insight [1]. >> It's also worth mentioning that Postgres has support for JSON field type >> [2] which satisfies many of the use cases for document store, though I >> haven't finished my own experiments yet so can't comment on comparative >> performance/functionality. >> >> It's industry knowledge that MySQL is bleeding out, rapidly [3] [4]. At >> this point, I introduce you to Monty and his creation MariaDB [5]. Although >> I would agree with Russell on many of the points he's made about MySQL, >> it's hard not to have respect for the work that Monty and his team have >> done previously on MySQL, and the vision that is now MariaDB. I would >> strongly recommend you spend some time looking into this yourself, read as >> many comparison articles as your eyes will allow, and come to your own >> conclusions. >> >> I have built numerous "large scale" systems with a variety of >> technologies.. Sphinx, ElasticSearch, MongoDB, MySQL, CouchBase, Redis. >> I've also spent many years battling with MongoEngine and have learnt to >> hate it, as much as I now hate the Django ORM. So, unless you are edging >> towards terabytes of data, assuming you are using SSDs and high memory >> nodes, then the impact of your choice will probably be negligible. And if >> you are using the Django ORM, then you are even less likely to reap any of >> these benefits out of the box [6] There are many different reasons for >> choosing one over the over, and you should assess this based on your own >> use case/needs/skills, rather than religious bias. >> >> Determine your use case and test all viable options, otherwise you could >> be avoiding something for the wrong reasons. You can build *beautiful* >> things with all these different technologies, and it's actually the mindset >> which matters the most [7]. Don't just settle for what others are telling >> you, try for yourself and come to your own conclusions, only then can you >> be sure. It's also a good way to gain in-depth knowledge about how these >> technologies work, which can be invaluable. >> >> Cal >> >> >> [1] https://blog.serverdensity.com/mongodb/ >> [2] http://www.postgresql.org/docs/9.3/static/datatype-json.html >> [3] http://www.theregister.co.uk/2012/11/29/monty_oracle_eu_promises/ >> [4] http://www.computing.co.uk/ctg/news/2271011/mysql- >> creator-monty-widenius-wants-it-to-disappear-from-the-earth >> [5] http://www.themukt.com/2014/09/11/reason-use-mysql-michael-widenius/ >> [6] https://news.ycombinator.com/item?id=4076834 >> [7] http://www.amazon.co.uk/The-Clean-Coder-Professional- >> Programmers/dp/0137081073 >> >> >> >> On Sat, Dec 6, 2014 at 12:26 AM, Russell Keith-Magee < >> rus...@keith-magee.com> wrote: >> >>> >>> On Fri, Dec 5, 2014 at 8:56 PM, Artie <giliar...@gmail.com> wrote: >>> >>>> Good day, Community, >>>> >>>> I'm looking for advise on MySQL & MongoDB usage so please let me take >>>> your time to describe the situation. >>>> >>>> I came to work on e-commerce shop of electrical components with about >>>> 10 millions of products. Now all of it stored in awful structure of tables >>>> in MySQL. Products stored in 10 small tables, each of them represents >>>> individual manufacturer of products and 1 generalized table, where all 10 >>>> millions of goods is stored. Those big table serves Sphinx search to >>>> implement search on site. >>>> All these products being crawled from several APIs and sites on web, so >>>> this shop is kind of authorized reseller in our region. >>>> >>>> The case is that we have to update all products daily and parsing with >>>> updating of products takes very long time. >>>> >>>> I have an idea to start using MongoDB to update and store products and >>>> as I think it might take less time than same in MySQL. First question: Am I >>>> correct with this statement? >>>> >>>> Browsing web I've found that some recommend using pymongo, avoiding >>>> django rather than mongodb for django. So for your opinion is this >>>> statement correct? >>>> >>>> Also it will be highly highly appreciated if you can share your >>>> personal use experience with MongoDB and any information you think be >>>> useful. >>>> >>> >>> Hi Artie, >>> >>> Can I make an alternate suggestion? Get a real database. >>> >>> In all honesty, I've never heard anyone in the Django community express >>> a deep love of MySQL or MongoDB. I know people who use MySQL, but when they >>> admit that, they say "Yeah, I know, but the customer required it" or "Yeah, >>> I know, but at the time we started it was the only thing Amazon supported". >>> As for MongoDB, the sentiment is usually "... and that was our first >>> mistake.". >>> >>> Personally - I have very little time for MySQL. It gets a number of key >>> design decisions wrong (for example, InnoDB's implementation of row >>> referential integrity is *demonstrably* incorrect). It has some default >>> behaviours that beggar belief (e.g., on MyISAM, by default, a row with a >>> "WHERE field IS NULL" clause that matches no results, and the previous >>> statement was an insert, the query will not return no results, but the >>> primary key of the last row inserted. By design [1][2]). And MySQL's usage >>> of indexes is woefully naïve - to the point where "performance optimising >>> for MySQL" often means "Roll out the results of an inner query and pass >>> them in as arguments, rather than just using a subquery". >>> >>> [1] https://code.djangoproject.com/ticket/14661 >>> [2] https://groups.google.com/forum/#!topic/django- >>> developers/1BgLit316XA >>> >>> And then you have MongoDB - a database that exists, as far as I can make >>> out, to overcome the deficiencies in MySQL. If you'd just started with a >>> real database, you wouldn't have hit the problems with MySQL, and you >>> wouldn't have to go looking for an exotic solution to overcome those >>> problems. >>> >>> If you're looking for performance, you're going to get much better >>> performance out of PostgreSQL, for the same price you paid for MySQL, with >>> the added benefit that PostgreSQL developers appear to have actually >>> consulted the SQL specification when they implemented their database. They >>> also have a query planner that will actually *use* indexes, instead of just >>> keeping them for decoration like MySQL does. >>> >>> If you're looking for a "schemaless" data store - well, PostgreSQL >>> hstore fields [3] have you covered. To the extent that people have actually >>> developed "MongoDB in PostgreSQL" [4]. And those stores outperform MongoDB >>> [5]. >>> >>> [3] http://www.postgresql.org/docs/9.0/static/hstore.html >>> [4] https://github.com/torodb/torodb >>> [5] http://blogs.enterprisedb.com/2014/09/24/postgres- >>> outperforms-mongodb-and-ushers-in-new-developer-reality/ >>> >>> So - in all honesty, I'd start by reconsidering your initial >>> assumptions. >>> >>> Yours, >>> Russ Magee %-) >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-users...@googlegroups.com. >>> To post to this group, send email to django...@googlegroups.com. >>> Visit this group at http://groups.google.com/group/django-users. >>> To view this discussion on the web visit https://groups.google.com/d/ >>> msgid/django-users/CAJxq84-FKrcBeB5joYTAP97dreo5cDmu_ >>> 2rxbutrQNm%3DAFru3g%40mail.gmail.com >>> <https://groups.google.com/d/msgid/django-users/CAJxq84-FKrcBeB5joYTAP97dreo5cDmu_2rxbutrQNm%3DAFru3g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAHKQagEL43ADbTRZGNp9tt%3DPU8%2BgodxxcT8mfaaukffXCk_Hgw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
