How can one best represent this type of data in a relational database?
There a variable number of a particular Machine each uniquely serialized by the manufacturer.
Each Machine will be set up by the user to do variable number of the tasks that this type of machine is capable of.
All the machines will select from the same task list which itself may be altered
over time
Finally each task will have a time setting which will vary from one machine to another.
The final condition seems to mess up my attempts to normalize this.
Machines :: Id, SerialNumber
Id is the primary key.
Tasks :: Id, Description
Id is the primary key.
MachineTasks :: MachineId, TaskId
MachineId and TaskId are the composite primary key. MachineId is a foreign key referencing Machines.Id. TaskId is a foreign key referencing Tasks.Id.
ScheduledMachineTasks :: MachineId, TaskId, Time
MachineId and TaskId are the composite primary key. MachineId and TaskId are a composite foreign key referencing MachineTasks.MachineId and MachineTasks.TaskId.
Note that this will only allow to schedule each task only once per machine and requires further extension if one task may be scheduled multiple times per machine.
Create a common table relating each object to each other, with that supplemental data.
MACHINE TABLE
ID, MachineID
TASK TABLE
ID, Task
MACHINETASK TABLE
ID, MachineID (FK to MACHINE.ID), TaskID (FK to TASK.ID), Time
Related
I am running a script to update a table structure, my problem is with the primary key column (id), the query creates a new id column each time I run my script.
This the first time that I am trying to write a script to update a database structure.
The database was created by an old version of an application,and now we want to release a new version of the application, but to achieve this goal I wrote a script which in summary is creating tables if they don't exist, adding columns to the tables if they don't exist, deleting old indexes and creating the new ones, etc.
The problem happens when the scripts add the primary key in the tables, in the database, the tables have a primary key column of type integer. But my query is not detecting this primary key column and it creates a new column with the same name and data type, at least that is what I see in PGAdmin v4.8.
Originally the primary key columns were created using the type serial and then PostgreSQL automatically creates a sequence and use it for the primary key.
How can I avoid the duplicated primary key columns?
Originally the column was created like follows
create table mytable(
id serial,
.
.
.
);
And if I look in the table, the column looks like this, which means that PostgreSQL created a sequence mytable_id_seq and used it for the auto increment value of primary key column.
id integer NOT NULL DEFAULT nextval('mytable_id_seq'::regclass)
But after I execute the following query and look in the table, it has a new column with the same name and data type like the one in the previous lines.
ALTER TABLE public.mytable ADD COLUMN IF NOT EXISTS id serial;
I am expecting to see only one column no matter how many times I execute the query.
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.
Does the userId of a preferenceArray need to be unique across all entries in a FastByIDMap?
I'm comparing two types of objects that contain similar traits however it's possible that their id (primary key) is not unique as it's two db tables.
Thanks.
Via the Mahout user mailing list, userID's in a FastByIDMap must be unique over the entire map.
I have an Order object which can be in an unpaid or paid state. When an order is paid, I want to set an order_number which should be an incrementing number.
Sounds easy enough, but I'm worried about collisions. I can imagine one order having an order_number stored in memory, about to save and then another order saves itself, using that number, now the one in memory should be recalculated, but how?
You can create a database table that just contains an AUTO_INCREMENT primary key. When you need to to get a new order_number just do an insert into this table and get the the value of the primary key for the created row.
There are a lot of approaches. Essentially you need a lock to ensure that each request to the counter always return a different value.
Memcache, Redis and some key-value stores have this kind of counter feature. eg, each time you want to get a new order_number, just call the incr command of Redis, it will increment the counter and return the new value.
A more complex solution can be implemented via the trigger/stored procedure/sequence features of RMDBS(like mysql). For mysql, create a new table contains an AUTO_INCREMENT primary key. When you want to get a new order_number, make an insert into this table and get last_insert_id(). If you want ACID, just wrap the procedure in a transaction.
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.