I am doing my first database project.
I would like to know which of the following ways should I use to make SQL queries in DDL.
#1
CREATE TABLE employees (
id INTEGER PRIMARY KEY,
first_name CHAR(50) NULL,
last_name CHAR(75) NOT NULL,
dateofbirth DATE NULL
);
#2
CREATE TABLE employees (
id INTEGER PRIMARY KEY,
first_name CHAR(50) NULL,
last_name CHAR(75) NOT NULL,
dateofbirth DATE NULL
);
#3
CREATE TABLE employees (
ID integer PRIMARY KEY,
FIRST_NAME char(50) NULL,
LAST_NAME char(75) NOT NULL,
DATAOFBIRTH data NULL
);
It doesn't really matter to the database, and so you should generally go for what's more readable and maintainable. There are a lot of different conventions out there, and I switch between them depending on circumstances all the time. Imo, what's good for a small query isn't the same as what's good for a more-complicated query.
In this case, I think your #3 looks most readable. But that's just my opinion and if there are conventions or existing expectations for how the code looks where you are, stick to that.
Sql coding Convections suggest :
CREATE TABLE employees
(
id INTEGER PRIMARY KEY,
first_name CHAR(50) NULL,
last_name CHAR(75) NOT NULL,
dateofbirth DATE NULL
);
Related
I'm new to SQL and am following a course, however it does not cover the "create table" part.
It only covers statements etc.
What I would like to have is, my primary key (cust_id) to be generated with the "first_name" and the first 3 letters of "last_name".
I.E. I want "John Smith" to become "custid"; JOHNSMI.
I have below code which works (without composite).
CREATE TABLE NL_client (
custid INT PRIMARY KEY IDENTITY (10000, 1),
userid VARCHAR (50) NOT NULL,
first_name VARCHAR (50) NOT NULL,
last_name VARCHAR (50) NOT NULL,
birthday DATE
);
And I found below code (last line added)
CREATE TABLE SAMPLE_TABLE (
custid INT,
userid VARCHAR (50) NOT NULL,
first_name VARCHAR (50) NOT NULL,
last_name VARCHAR (50) NOT NULL,
PRIMARY KEY (first_name, last_name),
);
However, when trying to execte the second query as displayed above it does not create a Primary key. Or when I execure the below queries;
custid INT PRIMARY KEY (first_name, last_name),
Either above in the query or at the end, it does not make a primary key.
Furthermore, I have no idea, nor was I able to find (perhaps I searched wrongly, surely I'm not the first with this "problem") how to select only the first 3 letters of "last_name" to be used as a part of the "custid".
Perhaps this is not possible and I should use "custerid" as an INT Primary key and use "userid" as a composite.
But it would surely help me in the future to be able to use the Primary Key as a reference in Python.
Many thanks in advance for your help and let me learn to understand why it doesn't work!
I am learning Azure and data analytics with Azure. Recently finished learning Postgresql.
My question is if there is an alternative to BIGSERIAL data type for Azure Databases. I ran the query (below the error in the following) and had an error. Note that this datatype exists in Postgresql and hence I am getting confused in Azure. Any alternative to BIGSERIAL?
Failed to execute the query. Error: Column, parameter, or variable #1:
Cannot find data type BIGSERIAL.
create table person (
ID BIGSERIAL NOT NULL PRIMARY KEY,
first_name VARCHAR(50) NOT NULL,
last_name VARCHAR(50) NOT NULL,
email VARCHAR(50),
gender VARCHAR(50) NOT NULL,
date_of_birth DATE NOT NULL,
Country_of_birth VARCHAR(50) NOT NULL
);
In PostgreSQL, the SERIAL keyword is used to setup an auto increment column, this works similar to auto increment in SQL. BIGSERIAL is an auto-incremented Bigint column of 8 bytes.
Closest, I could find "bigserial"in MS docs is as here
So...you can use BIGINT instead, below works fins for me.
create table person (
ID BIGINT NOT NULL PRIMARY KEY,
first_name VARCHAR(50) NOT NULL,
last_name VARCHAR(50) NOT NULL,
email VARCHAR(50),
gender VARCHAR(50) NOT NULL,
date_of_birth DATE NOT NULL,
Country_of_birth VARCHAR(50) NOT NULL
);
I have just started with IBM db2 and am running an sql query which I suppose is right. But nothing is happening when I hit the run button. Could anyone help?
Create table INSTRUCTOR
CREATE TABLE INSTRUCTOR
(ins_id INTEGER PRIMARY KEY NOT NULL,
lastname VARCHAR(15) NOT NULL,
firstname VARCHAR(15) NOT NULL,
city VARCHAR(15),
country CHAR(2)
);
Under the result area it is displaying "waiting" and nothing actually happens.
Try
CREATE TABLE INSTRUCTOR
( ins_id INTEGER PRIMARY KEY NOT NULL,
lastname VARCHAR(15) NOT NULL,
firstname VARCHAR(15) NOT NULL,
city VARCHAR(15),
country CHAR(2)
);
That should work for you assuming that you have ; set as the statement terminator in your query interface (it is the default in most SQL interfaces for Db2).
Alternatively, it might be that your CREATE TABLE is waiting for a lock on the system catalog. You can look at currently held lock with MON_GET_LOCKS https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.5.0/com.ibm.db2.luw.sql.rtn.doc/doc/r0056428.html
CREATE TABLE employees (
id INT NOT NULL auto_increment PRIMARY KEY (ID),
first_name VARCHAR(20) DEFAULT NULL,
last_name VARCHAR(20) DEFAULT NULL,
salary INT DEFAULT NULL);
I think this is correct query to create table in Oracle database.. but it gives the following error:
ORA-00907: missing right parenthesis
How to correct the statement?
You can validate your SQL using formatting tools such as http://www.dpriver.com/pp/sqlformat.htm
auto_increment seems like a proprietary MySQL extension, so it's not valid for Oracle.
also, "id int not null auto_increment primary key (id)" does not need the last "(id)"
Using Oracle, you shoud try something like this
CREATE SEQUENCE seq;
CREATE TABLE employees
(
id INTEGER NOT NULL PRIMARY KEY,
first_name VARCHAR2(20) DEFAULT NULL,
last_name VARCHAR2(20) DEFAULT NULL,
salary INTEGER DEFAULT NULL
);
INSERT INTO employees
VALUES (seq.NEXTVAL,
'name',
'last name',
1);
Sometimes, SQL is fancy, because even having a standard (ANSI), most DBMS vendors add their proprietary extensions to the SQL creating their own languages, so it's rare the situation where you can port one SQL from one DB into another without any changes.
Also, it's a pretty useless error message. It could at least say which position. (also, there's no missing parenthesis, but an unexpected token)
EDITED : New feature 12c
CREATE TABLE employees(
id NUMBER GENERATED ALWAYS AS IDENTITY,
first_name VARCHAR2(30)
etc.
);
Why would you do default null?
The VARCHAR datatype is synonymous with the VARCHAR2 datatype. To avoid possible changes in behavior, always use the VARCHAR2 datatype to store variable-length character strings.
Replace
id INT NOT NULL auto_increment PRIMARY KEY (ID),
with
id INT NOT NULL auto_increment PRIMARY KEY,
this is more efficient
CREATE TABLE EMPLOYEES_T(
ID NUMBER,
FIRST_NAME VARCHAR2(20) DEFAULT NULL,
LAST_NAME VARCHAR2(20) DEFAULT NULL,
SALARY INTEGER DEFAULT NULL,
CONSTRAINT PK_EMPLOYEES_T PRIMARY KEY(ID)
);
is this in 3NF ?
create table movies(
id numeric primary key not null default autoincrement,
name varchar(50) not null,
release-date Date,
price numeric,
rating numeric,
length numeric,
description varchar(1500)
);
create table movies(
id numeric primary key,
name varchar(20)
);
create table genre(
name varchar(20) primary key
);
create table directors(
id numeric primary key not null default autoincrement,
first-name varchar(32) not null,
last-name varchar(32) not null,
gender varchar(8),
dob Date,
biography varchar(1000)
);
create table movie-Star(
id numeric primary key not null default autoincrement,
first-name varchar(20) not null,
last-name varchar(20) not null,
gender varchar(8),
dob Date,
hometown varchar(20)
);
create table movies-cast(
movie-id numeric references movies(id),
actor-id numeric references movie-Star(id),
role varchar(32),
primary key (movie-id, actor-id)
);
Create table Studio(
studio-id numeric references directors(id)
Directer-name varchar(20) not null
name varchar(20) primary key
);
create table directors(
id numeric primary key not null default autoincrement,
first-name varchar(32) not null,
last-name varchar(32) not null,
gender varchar(8),
dob Date,
biography varchar(1000)
);
It looks pretty well structured. I don't see any normalization problems. However:
Movies and Directors tables are created twice.
Genre table is not used for anything (presumably should be in movies).
Same with Studios.
Current arrangement allows only one director per studio. This should probably be A) one studio per director (add studio_id column to directors) or more likely B) many-to-many relationship between studio and director (add new studio_directors table).
Current arrangement does not associate Director with Movie.
You might consider combining Director and Movie-Start into one table called Talent. You have data duplication in which a star is also a director. This is the biggest normalization issue with your design.
if all can not be duplicated again then it is included 3NF.
make sure there are not duplicate data again
It has e PK, so it's in 1NF. It's PK is not composite, so it's in 2NF. All the columns are dependent on nothing but the key, so it's in 3NF. There no keys other than PK, so it's in BCNF.