Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 8 years ago.
Improve this question
I am an SQL Rookie, I am trying to create a table but I have this error.
CREATE TABLE User
(
UserID int NOT NULL PRIMARY KEY,
UserName varchar(50) NOT NULL,
Email varchar(50) NOT NULL UNIQUE,
MembershipInfo varchar(50),
MembershipRank varchar(50),
CatID int,
CONSTRAINT CatID FOREIGN KEY(CatID) REFERENCES Category(CategoryID)
)
USERis a reserved word in Oracle and can't be used as a table name. The solution is to use another name.
USER is a reserved word. While it may be technically possible to force the database to let you create a table using a reserved word, it's a really bad idea. Just pick a new name - USERS is popular for this reason.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
I have a question about designing a table for events.
Which one is better using a multi-column primary key, or using a sequential primary key with multi-column unique index?
Columns of this table are like this:
Generally in SQL Server, PRIMARY KEY is created as unique clustered index in the background.
So, it is good practice to keep clustered index key as:
Unique (avoids effort to add uniquifier to make the value unique)
Narrow (does not occupy lot of space)
Incremental (avoids fragmentation)
So, in your case , it is better to go for
Sequential Primary key & multi column unique index
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 7 years ago.
Improve this question
I have a hierarchical table - it would suit a self referencing style, like this example I found.
CREATE TABLE OurStuff
(
StuffID INT NOT NULL PRIMARY KEY,
StuffSubID INT NULL,
StuffName VARCHAR(10) NOT NULL,
CONSTRAINT fk_StuffID FOREIGN KEY (StuffSubID)
REFERENCES OurStuff(StuffID)
)
I have a similar table - however when I try to replicate using Visual Studio Server Explorer, I get an error message:
"The columns in table 'abc' do not match an existing primary key or
unique constraint"
I can understand why, but I don't know why the above which is cited as an example would work and mine does not.
UPDATE: Here the link to the page in the example “How do I create a self-referencing foreign key?”
UPDATE:
I think you've got the relationship reversed. The ProductTypeIDcolumn should be on the left under the "Primary key table" and the ProductTypeParentID column should be on the right under the "Foreign key table."
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
What are the good example columns for which I should never create an index? As per my understanding the clustered index should often be done on primary keys (default) as it represents base data as a whole. But on which columns I should never create a non-clustered index?
You cannot say for sure. The fact is: you cannot create an index on any column (or combination of columns) that has a max size of more than 900 bytes - so any columns like VARCHAR(1000) or VARCHAR(MAX) cannot be indexed.
Other than that - it reallly depends on what your system does! There's no magic rule what columns to index - or which to avoid.
In general: fewer indexes are better than too many. Most DB developers tend to over-index their databases - but as I said - this is really heavily dependent on the exact situation of your system - there's no simple, general rules to follow here.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I am making a database about cars going around a certain street. So I made a table that keep the information of the CarId and the date when the car passed the particular street. The car can pass the street millions time, I know I need to make another table for that to keep all the dates but I am confused. Please help. How the database should look like
Without knowing what database you're using, I'm going to assume MS SQL Server / SQL Express. The following SQL should fulfil your requirements
-- Stores details about individual cars
create table Car
(
ID int identity(1,1) primary key,
Registration varchar(10),
Make varchar(20),
Model varchar(50)
-- Add any other fields here
)
go
-- Stores details about each time a "known" car passes by the location
create table Sightings
(
ID int identity(1,1) primary key,
CarID int not null,
constraint Sightings_FK_Car foreign key (CarID) references Car (ID),
SightedAt datetime not null
-- Add any other fields here
)
Using meaningless integers as primary keys on the tables is a matter of personal preference. You could use something like the registration number of the car as the primary key on the first table and a combination of the car registration and time of sighting on the second. I prefer the meaningless integer for performance reasons.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Imagine I have a table with only 2 columns (FKs to other tables). I want to define "the primary key of this table is the combination of the 2 values".
What happens if I don't have a PK in this kind of table?
Without a UNIQUE constraint or unique index defined on the two columns, the table could have duplicate rows.
Also, a primary key is a clustered index by default: you would need to separately index the table for expected query performance.
Refer to another SO question and yet another SO question declared as a duplicate of it regarding the differences between primary key & unique constraints and unique indexes.