Hi Marco, Follow up on Jelle's notes : " I see, however, a NoSQL db is not going to give you a rich API querying the DB, right? " and " Conceptually I planted it between serialization and a relational DB. Is that correct? "
As far as I understood the Cassandra db (don't know if it's the same for other distributed db), objects are stored in key-value structures. Each key is a uid (the 'row'), each value is a tuple of 'columns'. Each row can have different number of columns, columns can be inserted, deleted etc. It seems actually very close to a persistent python dict, and cannot be considered as more 'serialization' oriented than a relational DB. I don't know about any available querying API and its features compared to SQL, but I'm quite sure the same operations can be performed (see for instance http://maxgrinev.com/2010/07/12/do-you-really-need-sql-to-do-it-all-in-cassandra/ ). Thomas 2011/1/5 M. Nawijn <naw...@gmail.com> > Hi Jelle, > > I *love* being corrected ;) > I love to correct :). > > I see, however, a NoSQL db is not going to give you a rich API querying > the > > DB, right? > Well, it depends a little on what you mean. For NoSQL db's as far as I > know, there is > no standard like SQL. However, if you talk about CouchDB, you can > write so-called views that > aggregate and report on documents in the database. Views can be > written different languages. > Natively, CouchDB views are written in Javascript. However, it is > also possible to write views in > Python. > > A sample (untested) in Python would be something like: > > def get_wheels(doc): > if doc.partname=='wheel': > yield doc.partid, doc > > Thus, the full python/javascript arsenal is available for querying the > database. > Applying the view to the documents in the database is expensive the first > time, > but very fast for any additional calls. This is similar to indexed > columns/tables in a > relational database. > > > Conceptually I planted it between serialization and a relational DB. > > Is that correct? > I am not sure. > > > > Is it not important to have the possibility of SQL like operations on the > > data? > Yes, this is very important, but fully supported by writing views. > > > Thanks for sharing your insight, > > -jelle > > > > On Wed, Jan 5, 2011 at 12:18 PM, M. Nawijn <naw...@gmail.com> wrote: > >> > >> Dear All, > >> > >> Interesting discussion, so here are my 2 cents. > >> > >> First a disclaimer, I am no database expert at all, but have > >> experimented with sqlalchemy, sqlite etc. In addition, I recently > >> experimented with CouchDB which is a NoSQL database. I don't agree > >> with Jelle that NoSql db's are really built for web 2.0 like > >> applications. As an example, CouchDb is used by CERN to distribute the > >> data obtained from their large hydron collidor > >> (http://www.readwriteweb.com/enterprise/2010/08/lhc-couchdb.php). In > >> my work, I used CouchDB to distribute live test data obtained from > >> physical tests. In particular, I used the replication feature of > >> CouchDB to synchronize a test database at our internal network > >> (directly hooked up to several data acquisition systems) and a > >> database in our DMZ used for live post-processing and monitoring of > >> the test. Databases like CouchDB can in my opinion be really usefull > >> for storing CAE data in collaborative environments. For example, > >> CouchDB is very document centric. In terms of CAE like applications I > >> can imagine that raw topological data is stored as binary data in the > >> document, while meta-data or OCC XDE data is stored in document > >> attributes. Searching metadata/XDE info would be very fast and > >> efficient and could easily be distributed over several databases. > >> > >> I will try to write a testcase in the next few weeks and post it here. > >> > >> Ciao, > >> > >> Marco > >> > >> > >> > built specifically for web 2.0 realtime applications with trillions of > >> > users. Query's are ran by code rather than sql statement and the DB is > >> > reduced to storing / retrieving key/values ( on a large number of > >> > machines > >> > ). > >> > I'm pretty confident its _not_ practical for our sort of purpose. > >> > I'm pretty sure it would be more productive to first mess about with > >> > something compact and efficient such as sqlite ( or whatever > relational > >> > db > >> > ;) > >> > Than again, what the hell do I know. > >> > Please refer to this wiki entry so you understand what schema-less > DB's > >> > are > >> > good for. > >> > Why not rely use a decent ORM like sqlalchemy? > >> > Cheers, > >> > -jelle > >> > _______________________________________________ > >> > Pythonocc-users mailing list > >> > Pythonocc-users@gna.org > >> > https://mail.gna.org/listinfo/pythonocc-users > >> > > >> > > > > > > > _______________________________________________ > Pythonocc-users mailing list > Pythonocc-users@gna.org > https://mail.gna.org/listinfo/pythonocc-users >
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
