views:

117

answers:

2

Hello. I am evaluating Amazon SimpleDB at this time. SimpleDB is very flexible in the sense that it does not have to have table (or domain) schemas. The schema evolves as the create / update commands flow in. All this is good but while I am using a modeling tool (evaluating MindScape LightSpeed) I require the schema upfront, in order for the tool to generate models based on the schema. I can handcraft domains in SimpleDB and that does help but for that I have to perform at least one create operation on the domain. I am looking for the ability to create domain schema only. Any clues?

+1  A: 

There is no schema in SimpleDB.

This is the reason why the NoSQL people suggest to "unlearn" relational databases before shifting the paradigm to these non-relational data stores.

So, you cannot do what you describe. Without the data, there will be nothing.

Daniel Vassallo
Very true ... but if I have dependency on tools like LightSpeed, I cannot proceed with the new paradigm. I've been contemplating using Amazon RDS (MySQL) but don't want to shell out that much. Do you know of an ORM that respects this paradigm?
Kabeer
In LightSpeed Designer, you should be able to use the "model first approach". You do not need to have the database before the model. (http://www.mindscape.co.nz/products/lightspeed/features/designer.aspx)... Or maybe I did not fully understand your problem?
Daniel Vassallo
From what I have experienced so far, one cannot synchronize SimpleDB from the model. It is one way only (DB to model). For other RDBMSs, it works both ways.
Kabeer
+1  A: 

While it's true that SimpleDB has no schema support, keeping some type information turns out to be crucial if you run queries on on numeric data or dates*. Most NoSQL products have both queries and types, or else no-queries and no-types, but SimpleDB has chosen queries and no-types.

As a result, integrating with any tool outside of your main application will require you to either:

  1. store duplicate type information in different places
  2. create your own simple schema system to store the type information

Option 2 seems much better and choosing it, despite what some suggest, does not mean that you "don't have your mind right."

S3 can be a good option for this data, you can keep it in a file with the same name as your domain and it will be accessible from anywhere with the same AWS credentials as your SimpleDB account.

Storing the data as a list of attributename=formatname is the extent of what I have needed to do. You can, in fact, store all this in an item in your domain. The only issue is that this special item could unintentionally come back from a domain query where you are expecting live data not type information.

I'm not familiar with MindScape LightSpeed, but this is a general strategy I have found beneficial when using SimpleDB, and if the product is able to load/store a file in S3 then all the better.

*Note: just to be clear, I'm not talking about reinventing the wheel or trying to use SimpleDB as a relational database. I'm talking about the fact that numeric data must be stored with both zero padding (to a length of your choosing) and an offset value (depending on if it is signed or unsigned) in order to work with SimpleDB's string-base query language. Once you decide on a format, or a set of formats to be used in your application, it would be folly to leave that information hidden in and scattered across your source files in the case where that information is needed by source code tools, query tools, reporting tools or any other code.

Mocky