Bertrand Dunogier wrote: > 2010/6/23 Luc Chase <[email protected] <mailto:[email protected]>> > > > Disadvantages > > 1) slow > I would expect a huge improvement on current performance and I very > much doubt it would be slower. But if it is then, I would say do not > do it. > > Well, everything's relative, including performances... there is no such > thing as pure performances as far as the database's concerned. Non-SQL > DBs will definitely be faster when it comes to listing using search > criterias, for instance. That is actually why we recommend replacing > heavy content requests by solr searches ;) > > But it doesn't mean such a DB would be faster for everything. I for one > thing it might be slower when inserting / updating content; such > operations are very commonly asynchronous, and this might also be an issue. > > All of this is perfectly manageable. With time... > > In any case, about replacing the current "content DB" (we should first > identify which parts of the DB are part of the content engine and which > are not...), yes, there is an abstraction layer. But unfortunately, we > live in a world where database / query abstraction is far from perfect, > especially back a few years ago. Refactoring all of this is planned, > but parallel work on such an integration will (or would) severely > increase developement time. And will also add up again when the public > API is refactored.
What do you mean exactly with 'parallel work'? Parallel to what? 'Add up again' - I think on the contrary that when the public API is/will be redesigned, it will need to take into account this possible change in its underlying data-storage layer to avoid being obsoleted fast. So it would be better to have a working prototype of a different storage engine now, to check that the new public api is compatible with it... > But yes, when it comes to extracting & rendering content, such a no-SQL > DB would probably be much more efficient. Not that much for UGC & social > stuff though... right ? > > -- > Bertrand > -- Sdk-public mailing list [email protected] http://lists.ez.no/mailman/listinfo/sdk-public
