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
