I'm evaluating Amazon . com SimpleDB at this time around. SimpleDB is extremely flexible meaning that it doesn't need to have table (or domain) schemas. The schema evolves because the create / update instructions flow in. All of this is nice but as i am utilizing a modeling tool (evaluating MindScape LightSpeed) I require schema upfront, to ensure that the tool to create models in line with the schema. I'm able to handcraft domain names in SimpleDB which helps but for your I must perform a minumum of one create operation around the domain. I'm searching for a chance to create domain schema only. Any clues?
There's no schema in SimpleDB.
Because of this , why the NoSQL people suggest to "unlearn" relational databases before shifting the paradigm to those non-relational data stores.
So, you can't do that which you describe. With no data, you will see nothing.
While so SimpleDB doesn't have schema support, keeping some kind information works out to become crucial should you run queries on on number data or dates*. Most NoSQL items have both queries and kinds, otherwise no-queries with no-types, but SimpleDB has selected queries with no-types.
Consequently, integrating with any tool outdoors of the primary application will need you to either:
- store duplicate type information in various places
- make your own simple schema system to keep the kind information
Option 2 appears far better and selecting it, despite what some suggest, does not necessarily mean that you simply "do not have the mind right."
S3 could be a wise decision with this data, you can preserve it inside a file with similar title as the domain and it'll be around everywhere with similar AWS qualifications as the SimpleDB account.
Storing the information as a listing of attributename=formatname may be the extent of the items I've required to do. You are able to, actually, store all of this within an item inside your domain. The only real problem is this fact special item could inadvertently return from the domain query where you stand expecting live data not type information.
I am unfamiliar with MindScape LightSpeed, but this can be a general strategy I've discovered advantageous when utilizing SimpleDB, and when the merchandise has the capacity to load/store personal files in S3 then all of the better.
*Note: simply to be obvious, I am not speaking about reinventing the wheel or attempting to use SimpleDB like a relational database. I am speaking concerning the fact that number data should be saved with both zero padding (to some period of your selecting) as well as an offset value (based on if it's signed or unsigned) to be able to use SimpleDB's string-base query language. Once you choose a format, or some formats for use inside your application, it might be folly to depart that information hidden in and scattered across your source files within the situation where that details are required by source code tools, query tools, confirming tools or other code.