[Maya/Python] - Database for large amounts of simple information. Best?

Hey guys,

I have another general question for you to help me in my search for setting up some tools at work! (I’m sure ya’ll are thrilled!)

So I’m trying to develop a solution that takes an object in Maya, collects it’s width, height, depth information and can store that information in a database under 6-12 sections/groups. In essence I’m looking to categorize specific parts that are used over and over again in production, under sections so that the database can be queried and tell what “section” or group the part falls under.

A bolt for instance is a common object in our scenes that is used over and over again. It will have specific height/width/depth information that will remain constant. I want to use this information to designate the bolt is a bolt in the Maya scene so that it is treated as such!

I need to be able to write information to a data base (width, height, depth, designator ID) and I need to be able to query the database to cross check the information to categorize. Eventually this database will be queried by a small 2-3 person team (perhaps at the same time), but will only be written/modified by myself.

What would be the simplest database solution to do this? SQL Lite? Perhaps just an XML file that will be parsed by DOM or SAX (probably SAX considering there will be close to 1000 entries in this database and I don’t know if 1000 simple entries would kill memory)? Originally I was going to use a .ini config file, but I don’t think that would be a very sustainable solution considering the large amounts of entries (simple or otherwise… a config file is used for preferences more-so anyways.)

Not asking you guys for specific code, or in-depth solutions, but just what solution would be the best to learn, research and implement (and why).

Many thanks and I greatly appreciate your time.

SQL Lite is pretty easy to get up and running. It’s a good place to start.

Might be overkill for what you want to do, but I can’t wait to get some time to play with couchbase

Sounds like SQL Lite would be the way to go. I’ll start reading up on it’s functionality and figure out the approach to implement. Thank you for your time and suggestions!

SQLite is great unless you want other people to hit the same server! It’s local only : SQLite Is Serverless

If you’re going to share the database over a network and want an actual server, MySQL and Postgres both have python wrappers. The SQL portion is going to be quite similar but not identical.

+1 SQLite.

Another question of my own here. If I was to record timestamp in my database, how reliable is SQLite? It doesn’t support timestamp natively but can store it as text/float was what I gather. I want to migrate away from my current Postgres, if possible I’d love to use what Python can natively support.

You can just store time as either integers or text, but you have to push them in string format

As above, the main argument against SQLite is the lack of server support. When that’s not relevant it’s a great choice.

Sounds like MongoDB might be a good DB for you, when you couple this with a very simple API (say a simple RESTful PHP API) you can do extremely fast lookups of data from pretty any language that supports URL requests (say Python urllib2 or Requests)

It also has the added benefit of removing pretty much any dependency on special modules that would otherwise be needed to communicate with the database.

https://github.com/martinbean/api-framework
https://docs.python.org/2/library/urllib2.html

Every database is meant for large amounts of simple information. It’s the complement to the file-system, that are better at less amounts of complex information. But I would also suggest MongoDB, or any JSON-based datastore really, simply because it maps 1-1 to Python’s dictionary, meaning less cognitive overhead and simplified management.

Another point against SQLite would be performance. If you plan to write a lot of information at once that will be considerably slower in my experience.

Cheers,
Thorsten