I've just started on Amazon SimpleDB (first experience with noSQL), and while setting my first User domain, and adding the first item (with attributes id and name), i wondered what should the item name be?
Like RDBMS ids: "1", "2", "3" (so i should keep a count somewhere)
Uuids
More readable: "user_1", "user_2"
Will I be querying mostly by the item name? in this case is the item name equivalent to the id, therefore I don't need the id attribute?
Amazon SimpleDB simply requires a unique identifier for each row in your database. Item Name should be unique like your pk in your traditional database. When you query any data in Amazon SimplDB, you will get the list of items as a hits.
Item Name is not an attribute but if you are planning to add any new domain/table into Amazon SimpleDB and your any attribute will contain any unique data then you can replace your attribute with item name.
what should the item name be?
It's up to you- what you would really keep as an item name. You can keep among all three that you have suggested but It must be unique data like pk in your traditional database.
Will I be querying mostly by the item name? in this case is the item
name equivalent to the id, therefore I don't need the id attribute?
Yes. You can query your data using item name like -
select * from domain where itemName() = '1'
Related
I'm using DynamoDB to store my data. Each item has a name (primary key) and then unique attributes. How can I query by primary key, if the iOS DynamoDB sdk wants me to specify a model class (but each item is unique)? For example, I want to just input name (primary key), then the results will tell me what attributes that item has. Looking at aws's dynamodb sample for ios, you have to specify what these attributes are prior to the query, which I do not want to do. Is that the only way?
The examples you were looking at are for the Dynamo Mapper which is just one of the abstractions you can use to work with Dynamo. In fact it is a pretty high level one and it is convenient if all items have a limited set of known attributes.
But underneath Dynamo is a document database that only requireas items to have a key (that may optionally be composed of a partition and a sort key) but other than that you can definitely store and query each item with a different set of attributes.
Please have a look at the DynamoDB low level API (http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Programming.LowLevelAPI.html) which supports querying items by key, and then iterating over each item's attributes. In fact, items are treated as a key-value map where the key is the attribute name and the value is whatever you want to store for each attribute.
I wrongly mass uploaded a spreadsheet of data to a website. When I did this it assigned each row a unique id.
The problem arises when trying to create relations between the records. For ex: the restaurant "Foo" has 5 deals. But there is nothing linking each record together, other than the name Foo.
Should I just completely rebuild the app or is there a way that I can Assign all "Foo's" a unique id?
I have a simpledb column 'Status' I want to get rid of it. How can I delete it ? I dont see any intuitive way to do so.
Thanks
Since SimpleDB is a schema-less database each item may have different sets of attributes. In order to remove a particular attribute from all items you're going to need the itemNames for all items containing the attribute.
If you've decided to emulate a relational table in SimpleDB (by having one domain per 'table' and uniform attributes per item) you can retrieve all itemNames by a simple select query select itemName from domainX.
Once you've got the itemNames for the items which contain your unwanted attribute you'll need to call DeleteAttributes once for each item.
"a model with a uniquely indexed column"
Does this mean just a model and a column with a unique validation on the column? Or does it mean the column needs add_index in the migration?
And could you explain what exactly it means to create an add_index. Such as if you have an Authors model, with a name column. What does adding an index to 'name' accomplish?
Thanks.
I am taking it to mean that the model has a column that is guaranteed to be unique and that there is an index on it. I take it you are reading about models in general in Rails.
A unique column means that no two models (such as User1 and User2) can have the same value for that column. For example, users would have unique logins. No two users should exist that have the same login (or username or email). But Rails automatically gives models an ID column that is always unique. Unless you change it, the first record will have ID 1, then 2, then 3, etc.
An index on a column means that it is easier to find that column. Think of a an encyclopedia. There is so much information in there, but the appendix (like an index) helps you quickly find what you are looking for. There may be an appendix of key terms, and then it will tell you where to quickly find it. That's what an index on a column does.
So "a model with a uniquely indexed column" in Rails, by default, is the ID column: it is unique and will automatically get an index on it to more quickly find records.
Extra: when you make a model with a foreign key (example: model User may have a gender_id, and you may have a table called Gender that defines Male and Female and the gender_id corresponds to a Gender object), then you should add an index to that foreign key to make searches on it faster.
More information: http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/SchemaStatements.html#method-i-add_index
I'm writing my first rails app & want to get into some good habits from the start. The table in question is to be to hold employee data, one of the fields being the manager's ID. To reflect the hierarchical structure, I'm thinking of using acts_as_tree, so the parent_id would be the manager's id field (right?). If we are to use (import) data from our existing HR application - PeopleSoft - the employee ID is a string. Employee ID seems to make the most sense as a PK (coming from the PeopleSoft developer perspective, I realize I may be biased and/or not seeing all of the possibilities -- I welcome suggestions on this as well)
I know that one of the philosophies behind rails is "convention over configuration", so I'd like to use the defaults - the PK being the autoincrementing integer. Would it make sense in this case to create a "lookup table" or something in order to maintain the use/association of the ID coming from PS? There will be reports/exports going back into the PS world....
Thanks
You're correct in that the convention in Rails is to use the default auto-incrementing id. If you have a one-to-one relationship between people and employee IDs, then employee ID should just be a field (column) on your person model. Make it a key (but not a primary key) if you're going to be doing a lot of lookups using it.