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
);
Related
I have a database. As you can see the primary key is an auto_increment and is also unique. I read that publically sharing a row's primary key of a table to the public is unsafe. I want to assign each row in customers a unique ID that I can publically share. How can I do this without having to specify each time what the public_id is in the INSERT statement? The database should automatically find a unique ID to assign to that row just like it does for id because of auto_increment.
CREATE TABLE customers (
id int primary key auto_increment,
name varchar(32) not null,
-- public_id (an ID I can give to the public to uniquely identify this row
);
INSERT INTO customers (name) VALUES ('Bob'), ('Sarah'), ('Bob');
Well, here's one way:
CREATE TABLE customers (
id int primary key auto_increment,
name varchar(32) not null,
public_id char(36) not null unique default uuid()
);
Note that the manual says:
Warning
Although UUID() values are intended to be unique, they are not necessarily unguessable or unpredictable. If unpredictability is required, UUID values should be generated some other way.
So this is simple, and maybe will float your goat, but we can also try better:
CREATE TABLE customers (
id int primary key auto_increment,
name varchar(32) not null,
public_id char(24) not null unique default to_base64(random_bytes(18))
);
This will be a nice and dense identifier, but it will have characters + and / which don't play well with URLs. You can encode them, of course, but if you want to go one lazier, you can also do this:
CREATE TABLE customers (
id int primary key auto_increment,
name varchar(32) not null,
public_id char(32) not null unique default hex(random_bytes(16))
);
Mind you, the identifier will get quite a bit longer this way.
To get the best of both worlds, we can do this, at the expense of a really long default value:
CREATE TABLE customers (
id int primary key auto_increment,
name varchar(32) not null,
public_id char(24) not null unique default replace(replace(to_base64(random_bytes(18)), '+', '_'), '/', '-')
);
Also note that messing around with MD5()/SHA()/SHA1()/SHA2() is no better than just generating a random hex string with a given length.
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 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))
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.
If I have click data on a server that expects more than one click per second, is it practical to normalize timestamps?
Basically, this:
CREATE TABLE clicks(
id INT(6) UNSIGNED AUTO_INCREMENT PRIMARY KEY,
timestamp TIMESTAMP NULL
)
VS
CREATE TABLE clicks(
id INT(6) UNSIGNED AUTO_INCREMENT PRIMARY KEY,
timestamp_id INT(6) UNSIGNED NULL
)
CREATE TABLE timestamps(
id INT(6) UNSIGNED AUTO_INCREMENT PRIMARY KEY,
timestamp TIMESTAMP NULL
)
No, not at all. Only time you split stuff out into another table is if there is another piece of data associated with it you want to save by itself. Not the case here, and the timestamp is not going to get reused.