I have got the following JSON file:
"vehicle_number" : 91,
"pit_stops" : [ {
"pit_in_elapsed_time" : 1874.0926,
"pit_out_elapsed_time" : 0.0
}, {
"pit_in_elapsed_time" : 1992.9723,
"pit_out_elapsed_time" : 0.0
}, {
"pit_in_elapsed_time" : 2862.2129,
"pit_out_elapsed_time" : 0.0
} ],
My table has to keep the following value:
vehicle
pit_int_elapsed_time
pit_out_elapse_time
How do I create a table based on this??
create table pitstop (
vehicle varchar(50) not null,
inTime varchar(50) not null,
outTime varchar(50) not null,
constraint pk_id primary key(inTime, outTime))
I am not sure if this would be the ideal way of create the table?
Regards
EDIT
I have been thinking of creating 2 main tables. One for the vehicles (vehicleID as pk, pitstopFK as foreign key).
create table vehicles (
vehicle varchar(50) primary key not null
pitstops_fk int not null );
Also the pitstops table:
create table pitstops (
id int primary key autoincrement not null,
inTime varchar(50) not null,
outTime varchar(50) not null,
constraint u_time UNIQUE (inTime, outTime))
vehicles ----- pitstops ( 1 to many)
It's hard to say much without a better understanding of the problem you're trying to solve, but I would say:
if vehicle ID is always an integer, an unsigned int will generally perform better than treating it as text
using a SQL date type for the inTime and outTime columns will allow you to use SQL time/date operations. If the timestamps represent real-world times consider DATETIME or TIMESTAMP, if they are elapsed seconds since the start of a race or something like that, a floating point numeric type would probably be a better choice.
the combination of inTime and outTime doesn't make sense as a primary key, since as you note in the comment it is not necessarily unique. In thinking about designating a primary key, don't (just) think about uniqueness, but about how you'd want to refer to a pitstop event from other tables. In the case I would probably suggest a synthetic auto-incremented unsigned int as a primary key.
First of all, if it is a time you want to store in your database i wouldn't use varchar. Instead try to use Float or Real.
The next thing is, that you should take your vehicle in your primary key as well.
I also would recommend to introduce a ID to your Database.
Something like this:
CREATE TABLE pitstop (
ID int NOT NULL AUTO_INCREMENT,
vehicle varchar(50) NOT NULL,
inTime float NOT NULL,
outTime float NOT NULL,
constraint pk_id primary key(ID, vehicle))
Related
lets say I have an account object in my application, which currently represented as:
CREATE TABLE Account (
accountId int NOT NULL AUTO_INCREMENT,
name varchar(255) NOT NULL,
PRIMARY KEY (accountId)
);
Now, Account object need to also have Solution field...and Status have 4 different possible values:
Solution1, Solution2, Solution3, Solution4
What would be the right way to represent it in the database?
Account can have few statuses, and status can have few accounts...
So at first I thought create in the db table of Solutions and than have another table to hold the relationship, but its seems too complicated for a field that have only 4 possible values...
Create a junction table to represent the relationships between accounts and solutions:
CREATE TABLE account_solution (
accountId int NOT NULL,
solutionId int NOT NULL
PRIMARY KEY (accountId, solutionId)
)
For your solution table, since there are only 4 values, you might be able to take advantage of MySQL's enum type, e.g.
CREATE TABLE solution
solutionId int NOT NULL PRIMARY KEY,
status ENUM('Solution1', 'Solution2', 'Solution3', 'Solution4')
);
You can use set Mysql SET type
CREATE TABLE Account (
accountId int NOT NULL AUTO_INCREMENT,
name varchar(255) NOT NULL,
status set('Solution1','Solution2','Solution3','Solution4') NOT NULL,
PRIMARY KEY (accountId)
);
And if you want to select a specific status
SELECT *
FROM `Account`
WHERE FIND_IN_SET( 'Solution2', `status` ) >0
I am looking on internet for 3 hours, but i dont find any solution.
I would like to create an SQL database via script. I storing user weight and height in a table, but i do not know which is the best type for it.
SQL code
CREATE TABLE details (
ID int(11) NOT NULL AUTO_INCREMENT PRIMARY KEY,
user_id int(11) NOT NULL REFERENCES user(ID),
weight decimal(5,2) UNSIGNED NULL,
height tinyint UNSIGNED NULL
);
I want store height in cm [100 - 220]
and weight in Kg [30.0 - 150.0] example. weight -> ##.#
Edit:
This is MySQL server.
If this it mySQL you can make them both decimals like you did with weight:
CREATE TABLE details (
ID int(11) NOT NULL AUTO_INCREMENT PRIMARY KEY,
user_id int(11) NOT NULL REFERENCES user(ID),
height FLOAT,
weight FLOAT
);
You store the number in the data base, the fact that it is kg or meters or whatever is something you have to remember, or deal with after you get the data from the database.
If you want a way to remember what unit you are storing into the data base you can do this:
CREATE TABLE details (
ID int(11) NOT NULL AUTO_INCREMENT PRIMARY KEY,
user_id int(11) NOT NULL REFERENCES user(ID),
height_cm FLOAT,
weight_kg FLOAT
);
I have got only one column for a table when i create two localized tables. Code as bellow.
-- Month
CREATE TABLE `month` (
`id` INT PRIMARY KEY NOT NULL AUTO_INCREMENT,
);
-- Month Localized
CREATE TABLE `month_loc` (
`month_id' INT NOT NULL,
`name` VARCHAR(200) NOT NULL,
`description` VARCHAR(500) NOT NULL,
`lang_id` INT NOT NULL
);
month_loc.month_id is the foreign key.
month table holds only the primary key. Other all fields should be localized. Is this table structure correct ?
Thanks.
If correct implies a certain degree of normalization, and the content of your columns name and description vary per month_id, lang_id (which would be the combined primary key of month_loc), then yes, your design has reached the 3rd grade of normlization.
I'm working on an application which tracks prices for certain items.
Each price has a reference to an item, a business that sells that item, and the location the item is being sold at. Now, normally, this would do just fine:
CREATE TABLE `price` (
`priceId` INT UNSIGNED NOT NULL AUTO_INCREMENT, -- PK
`businessId` INT UNSIGNED NOT NULL,
`itemId` INT UNSIGNED NOT NULL,
`locationId` INT UNSIGNED NOT NULL,
`figure` DECIMAL(19,2) UNSIGNED NOT NULL,
-- ...
)
But I have the following problem:
The application logic is such that one item at one business at one location can have multiple prices (at this point it's not really important why), and one of those prices can be an official price - an item doesn't have to have an official price, but if it does, there can be only one.
The question is; how to model this to ensure data integrity?
My initial idea was to create an additional table:
CREATE TABLE `official_price` (
`priceId` INT UNSIGNED NOT NULL -- PK + FK (references price.priceId),
-- ...
)
This table would hold priceId:s for prices that are official, and the PK/UNIQUE constraint would take care of the 'one-or-none' constraint.
This seems like a workable solution, but I'm still wondering if there's a better way to handle this situation?
You can use this dirty hack:
add a field is_official to price table, null as a value is possible in it
create an unique composite index priceId + is_official
for the official prices put 1 to is_official
for not official left it to be null
You could make the price table hold only official prices (with the figure possibly null), put a unique constraint on (businessId, itemId, locationId), and add another table of auxiliary prices referencing priceId.
I am using a VARCHAR as my primary key. I want to auto increment it (base 62, lower/upper case, numbers), However, the below code fails (for obvious reasons):
CREATE TABLE IF NOT EXISTS `campaign` (
`account_id` BIGINT(20) NOT NULL,
`type` SMALLINT(5) NOT NULL,
`id` VARCHAR(16) NOT NULL AUTO_INCREMENT PRIMARY KEY
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
however, this works:
CREATE TABLE IF NOT EXISTS `campaign` (
`account_id` BIGINT(20) NOT NULL,
`type` SMALLINT(5) NOT NULL,
`id` VARCHAR(16) NOT NULL PRIMARY KEY
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
What is the best way to keep track of incrementation of 'id' myself? (Since auto_increment doesn't work). Do i need to make another table that contains the current iteration of ID? Or is there a better way to do this?
EDIT: I want to clarify that I know that using INT is a auto_increment primary key is the logical way to go. This question is in response to some previous dialogue I saw. Thanks
you have to use an INT field
and translate it to whatever format you want at select time
example of a solution to your problem:
create a file with a unique number and then increment with a function.
the filename can be the prefix and the file binary content represent a number.
when you need a new id to the reg invoque the function
Example
String generateID(string A_PREFIX){
int id_value = parsetoInt(readFile(A_PREFIX).getLine())
int return_id_value = id_value++
return return_id_value
}
where "A_PREFIX-" is the file name wich you use to generate the id for the field.
Or just create a sequence and maintain the pk field using the sequence to generate the primary key value with nextval function. And if perf is an issue, use cache on sequence.
But as others have stated, this is sub-optimal, if your primary key contains a numbered sequence then it's better to use int and auto-increment.
I don't see a use case where pk has to auto-increment but be a varchar data type, it doesn't make sense.
Assuming that for reasons external to the database, you do need that varchar column, and it needs to autoIncrement, then how about creating a trigger that grabs the existing autoIncrement value and uses Convert() to convert that value into a VarChar, dropping the VarChar into the field of interest. As mentioned in a previous answer, you could concatenate the table-name with the new varChar value, if there is some advantage to that.