sql missing or invalid option on create table statement

Question

I'm new to SQL, this segment should just make a few tables, right? I can't see anything wrong but Oracle says "missing or invalid option" on the line "CREATE TABLE Album"

CREATE TABLE Profile
(prid INTEGER,
first_name CHAR(20),
last_name CHAR(20),
year_of_birth INTEGER,
month_of_birth CHAR(9),
day_of_birth INTEGER,
gender CHAR(6),
PRIMARY KEY (prid))

CREATE TABLE Album
(aid INTEGER,
visible CHAR(20),
link CHAR(30),
create_time CHAR(30),
mod_time CHAR(30),
name CHAR(30),
owner_prid INTEGER,
PRIMARY KEY (aid),
FOREIGN KEY owner_prid REFERENCES Profile(prid))

Answer 1

cyberkiwi already answered your question about the syntax error.

Since you're new to SQL, however, I wanted to comment on the DDL itself. In particular, it looks like you're using the wrong data types for a number of these columns-- that's going to come back to bite you.

• Do not use the CHAR data type unless you have an extremely compelling reason to do so

Many Oracle users will go further and suggest that you never ever use a CHAR data type. The basic problem with using CHAR is that the data is blank padded. So if you store the word "Male" in the GENDER column and GENDER is a CHAR(6), Oracle has to store two additional spaces at the end of the string. That makes future comparison operations very perilous-- you have to make sure that CHAR comparison semantics are used rather than VARCHAR comparison semantics and that tends to get ugly. Additionally, you're wasting space on disk and in memory to store those two additional spaces for no benefit. All of your CHAR columns should really be VARCHAR2

• Store dates as dates-- don't store date components and don't store dates as strings

Rather than storing a YEAR_OF_BIRTH , MONTH_OF_BIRTH , and DAY_OF_BIRTH , you're almost certainly better off with a single BIRTH_DATE column of type DATE where you store the birth date. You can always extract the various date components if you want to find out what year someone was born. Storing the data as a DATE, though, will ensure that the date components themselves are valid (ie no typos where the month is listed as 'Febuary', no data quality issues where the month is sometimes 'Feb', sometimes 'February', and sometimes '2', no dates of February 30, etc.) Storing the data as a DATE gives the optimizer much more information to work with so it is more likely to generate the most efficient plan because it knows something about the data distribution. And you can use all the various date functions that Oracle provides.

By the same token, since CREATE_TIME and MOD_TIME are dates (an Oracle DATE always has a day and a time component), you should be storing them as DATEs (or TIMESTAMPs) rather than VARCHAR2's. That allows you to use date (or timestamp) functions, it ensures that the times are valid, it eliminates issues with different formats being stored in the same column, and it makes it much easier to use the various date functions.

Answer 2

If you are using Oracle XE and the browser interface, you cannot run multi-line statements. Split them into two statements and run one, then clear text, paste the other, then run again.

Your 2nd block should be

CREATE TABLE Album
(aid INTEGER,
visible CHAR(20),
link CHAR(30),
create_time CHAR(30),
mod_time CHAR(30),
name CHAR(30),
owner_prid INTEGER,
PRIMARY KEY (aid),
FOREIGN KEY (owner_prid) REFERENCES Profile(prid))

ie brackets around the field that forms part of the FK