Я пытаюсь создать эту таблицу в SQL Server 2008

Question

CREATE TABLE DEPARTMENTS
(Department_Id varchar(5) Primary Key NOT NULL,
 Department_Name char(20) NOT NULL,
 Manager_Id varchar(5) FOREIGN KEY REFRENCES EMPLOYEES,
 Location_Id FOREIGN KEY REFRENCES LOCATIONS)
GO

CREATE TABLE EMPLOYEES
(Employee_Id varchar Primary Key NOT NULL,
 First_Name char(20) NOT NULL,
 Last_Name char(20) NOT NULL,
 Email varchar(60) NULL,
 PhoneNumber varchar(13) NULL,
 Hire_Date date NOT NULL,
 Manager_ID varchar(5) FOREIGN KEY REFRENCES EMPLOYEES
 Department_IdFK REFRENCES DEPARTMENTS)
GO

CREATE TABLE LOCATIONS
(Location_ID varchar(5) Primary Key,
 Postal_Code no(5),
 City text(60),
 State_Province text(20),
 Country text(60))

Answer 1

Я бы снял ограничения, но вот, пожалуйста.

CREATE TABLE DEPARTMENTS (
Department_Id varchar(5) Primary Key,
Department_Name char(20) NOT NULL,
Manager_Id varchar(5),
Location_Id varchar(5)
) 
GO

CREATE TABLE EMPLOYEES (
Employee_Id varchar(5) Primary Key,
First_Name char(20) NOT NULL,
Last_Name char(20) NOT NULL,
Email varchar(60) NULL,
PhoneNumber varchar(13) NULL, 
Hire_Date date NOT NULL,
Manager_ID varchar(5),
Department_Id varchar(5)
)
GO

CREATE TABLE LOCATIONS (
Location_ID varchar(5) Primary Key,
Postal_Code varchar(5),
City varchar(60),
State_Province varchar(20),
Country varchar(60)
)
GO

ALTER TABLE DEPARTMENTS WITH CHECK ADD CONSTRAINT [FK_DepartmentManager] FOREIGN KEY([Manager_Id])
REFERENCES EMPLOYEES ([Employee_Id])
GO

ALTER TABLE DEPARTMENTS WITH CHECK ADD CONSTRAINT [FK_UserLocation] FOREIGN KEY([Location_Id])
REFERENCES LOCATIONS ([Location_Id])
GO

ALTER TABLE EMPLOYEES WITH CHECK ADD CONSTRAINT [FK_EmployeeManager] FOREIGN KEY([Manager_Id])
REFERENCES EMPLOYEES ([Employee_Id])
GO

ALTER TABLE EMPLOYEES WITH CHECK ADD CONSTRAINT [FK_EmployeeDepartment] FOREIGN KEY([Department_Id])
REFERENCES DEPARTMENTS ([Department_Id])
GO

Answer 2

Вы ошиблись REFERENCES как REFRENCES несколько раз.Попробуйте написать его правильно, чтобы увидеть, исчезнет ли проблема.

Answer 3

DEPARTMENTS REFERENCES EMPLOYEES
EMPLOYEES REFERENCES EMPLOYEES

Это затрудняет работу с этими таблицами.Кажется, вы позволяете им быть в состоянии NULL, зная, что для создания двух сущностей в двух таблицах вам нужно две INSERT с плюс две UPDATE с.

Кроме того, кажется,чтобы позволить менеджеру сотрудника отличаться от менеджера ее отдела - это предназначено?

Я бы "разработал" необходимость в NULL способных ссылках / ссылочных столбцах и создал бы две дополнительные таблицы отношений:

DepartmentalStaff REFERENCES Employees REFERENCES Departments
DepartmentalManagers REFERENCES DepartmentalStaff

Answer 4

Вы не упомянули, для какой базы данных это предназначено, и у вас там действительно странные типы данных ....

Некоторые общие комментарии (которые в основном относятся к SQL Server):

• в общем случае короткие строки (до 10 символов) могут и должны быть сделаны CHAR(x) - поэтому ваше Department_Id действительно должно быть char(5) полем

• CHAR(X) поля (по крайней мере, в SQL Server) всегда дополняются до полной длины пробелами - поэтому, если у вас есть Department_Id CHAR(5) и вы введете 'ABC', столбец будет содержать 'ABC..'

• поэтому столбцы, такие как имя и фамилия, должны определенно не быть CHAR(20) - если вы введете «Брюс» в first_name, вы получите «Брюс». ............. '- удачи, пытаясь найти что-нибудь на такой колонке! Используйте VARCHAR(20) вместо!

• если вы действительно используете SQL Server 2005 и более поздние версии, вам следует прекратить использование TEXT - этот тип данных устарел. Вместо этого используйте VARCHAR(MAX) - он обладает всеми преимуществами TEXT, плюс вы можете использовать все обычные строковые функции для него.

• моя личная рекомендация также состоит в том, чтобы использовать INT для таких вещей, как Location_Id - обычно присоединение и поиск по INT быстрее, чем по VARCHAR (5) - плюс с INT вам никогда не придется беспокоиться о неправильном написании, неправильном сопоставлении или о проблемах в верхнем и нижнем регистре. Если вы используете неописательный суррогатный столбец для своих идентификаторов, что, на мой взгляд, является хорошей вещью, я бы сделал это INT - не используйте строки для идентификаторов - это может привести к беспорядку (за исключением мест, где строки используется повсеместно - как государственные сокращения и т. д.)