Mysql
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Mysql

Lỗi 1005 trong MySQL (từ cú pháp khóa ngoại?)

Lỗi của bạn là do cú pháp khóa ngoại không chính xác.

Tuy nhiên, Tôi nghĩ bạn nên sử dụng trường ID thay vì sử dụng khóa chính hỗn hợp chuỗi . Có một số vấn đề với phương pháp của bạn ...

  • Nó sẽ khiến DB khó nối các bảng với nhau hơn so với việc sử dụng một trường số nguyên (ID) để tham gia (khó hơn ==nhiều thời gian xử lý hơn).

  • Việc có nhiều người có cùng tên, thậm chí sử dụng chữ viết tắt giữa là hợp lệ.

  • Điều gì xảy ra nếu bạn phải thay đổi tên của ai đó? Có thể là do nó được lưu trữ sai hoặc họ đã kết hôn hoặc bất cứ điều gì ... Điều đó có nghĩa là bạn sẽ không chỉ cập nhật employee của mình nhưng works bảng và bất kỳ bảng nào khác mà bạn đã sử dụng tên làm khóa ngoại.

Hãy xem phần này: http://sqlfiddle.com/#! 2 / 2dc8c / 3/0

Tôi đã thêm một ID bảng vào mỗi bảng . Nó là một unsigned int , có nghĩa là nó không thể là số âm (bởi vì điều đó sẽ không có nhiều ý nghĩa). Nó cũng là auto_increment , có nghĩa là mỗi khi bạn thêm một hàng vào bảng, ID này sẽ được tạo tự động và tăng lên 1.

    create table Employee (
          Employee_ID int unsigned auto_increment primary key,

          Lastname    varchar(10),
          FirstName   varchar(10),
          MidInitial  char(1),

          gender      char(1),

          street      varchar(10),
          city        varchar(10),

          unique (Lastname, FirstName, MidInitial)
      );

Bạn sẽ thêm những thứ vào bảng này như thế này:

    insert into Employee (Employee_ID, LastName, FirstName, MidInitial) 
                   values (null,       'Smith',  'John',    'K');

null sẽ trở thành ID được tạo tự động. Nó sẽ là duy nhất cho mỗi hàng.

Ngoài ra, một ràng buộc duy nhất có nghĩa là sự kết hợp của các trường này phải là duy nhất trong bảng. Tuy nhiên, với một công ty đủ lớn, tôi cá là hai người sẽ trùng tên. Trong cuộc sống thực, tôi sẽ đề xuất loại bỏ ràng buộc duy nhất này.

Tôi đã thực hiện các thay đổi tương tự đối với bảng công ty ...

     create table company(
         company_ID      int unsigned auto_increment primary key,

         company_name    varchar(20),
         city            varchar(10),

         unique (company_name)
    );

Những thứ có thể được thêm vào như:

     insert into company values (null, 'Taco Bell', 'Paris'); 

Vì vậy, ... cho works .... thay vì lưu trữ nhiều lần họ tên của từng người và tên công ty đầy đủ trong bảng này, bây giờ chúng ta chỉ phải lưu trữ ID.

    create table Works (
         works_id      int unsigned auto_increment primary key,

         employee_id   int unsigned, 
         compay_id     int unsigned,  

         salary        numeric(8,2), 

         foreign key (employee_id) references Employee (employee_id), 
         foreign key (compay_id) references company (company_id) 
    );

Bạn có thể thêm mọi thứ vào works như thế này:

    insert into Works values (null, 1, 1, '10.00');

Vì John Smith là nhân viên đầu tiên của chúng tôi, nên Employee_ID của anh ấy sẽ là 1. Để xác minh điều đó, chỉ cần thử select * from Employee where FirstName='John' and LastName='Smith' . Taco Bell cũng sẽ nhận được company_id =1. Bằng cách chèn các giá trị đó vào works , điều đó có nghĩa là John hiện đang làm việc tại Taco Bell.

Tôi cũng khuyên bạn nên thêm các trường như start_dateend_datejob_title vào bảng công việc của bạn. Và bạn cũng muốn đặc biệt xem xét bất kỳ ràng buộc duy nhất nào cho bảng này. Mọi người có thể làm việc cho cùng một công ty nhiều hơn một lần. Họ cũng có thể có những công việc khác nhau.

Khi bạn muốn lấy lại dữ liệu của mình, bạn sẽ sử dụng một truy vấn như sau:

  select FirstName, MidInitial, LastName, 
         Company_Name, 
         Salary 

  from   employee

         join works 
           on works.employee_id = employee.employee_id

         join company 
           on works.company_id = company.company_id 

đó chỉ là một cách nói hoa mỹ:

  select FirstName, MidInitial, LastName, 
         Company_Name, 
         Salary 

  from   employee, works, company

  where  employee.employee_id = works.employee_id and

         company.company_id = works.company_id  

Một số lưu ý về những điều trong cơ sở dữ liệu ...

  • Chọn một quy ước đặt tên và tuân theo quy ước đó! Nếu bạn muốn sử dụng CamelCase , sử dụng nó ở mọi nơi. Nếu you_want_to_use gạch dưới tên của bạn, sử dụng chúng ở mọi nơi. Có rất nhiều quy ước đặt tên để lựa chọn:thuộc tính tiền tố (cột / trường) với tên bảng, sử dụng các chữ viết tắt phổ biến (hoặc không), nơi sử dụng viết hoa (hoặc không) ... điều này chủ yếu phụ thuộc vào sở thích cá nhân nhưng có là các bài báo về ưu và nhược điểm của việc sử dụng một số cái nhất định. Lưu ý cuối cùng, _ chỉ vì bạn có thể sử dụng dấu cách trong tên, __ không có nghĩa là bạn nên làm như vậy. `Almost all` cơ sở dữ liệu cho phép [you use spaces] trong tên nếu bạn muốn nhưng nó có thể gây ra rất nhiều vấn đề sau này.

  • Tên bảng không được ở dạng số nhiều. Đây là một thú cưng của tôi và đây là lý do tại sao:Chúng tôi biết một bảng sẽ chứa nhiều hồ sơ ... nhiều người / nhiều người, nhiều nhân viên, nhiều công ty, nhiều mục nhập thuộc bất kỳ loại hoặc hình thức nào. Mỗi hàng chỉ mô tả một của những thứ này. Đôi khi nó thậm chí không có ý nghĩa khi đặt tên là số nhiều. Lần khác, nó có vấn đề - như works bàn. Nếu đôi khi bạn đặt nó là số nhiều và đôi khi đặt nó ở số ít, nó có thể trở nên khó hiểu sau này. Bằng cách chỉ biến nó thành số ít, nó vẫn có ý nghĩa hoàn hảo và bạn không phải chuyển qua chuyển lại hoặc phải tra cứu tên chính xác khi viết truy vấn.

  • Kiểu dữ liệu rất quan trọng và cố gắng nhất quán giữa các bảng cho các trường tương tự (như tất cả id s cùng loại; tạo tất cả các trường boolean tất cả các bit hoặc số nguyên hoặc bất cứ thứ gì, chỉ cần làm cho chúng giống nhau). Có nhiều kích thước khác nhau của kiểu số nguyên mà bạn có thể chọn. Hãy suy nghĩ về kích thước, hiệu suất và những gì phù hợp với nhu cầu của bạn. Quyết định xem bạn có thực sự cần một nvarchar hay một varchar có phù hợp hay không.

    • Ngày nên không bao giờ được lưu trữ dưới dạng một chuỗi. Sử dụng loại dữ liệu ngày, giờ, giờ hoặc dấu thời gian thích hợp . Điều này sẽ giúp bạn rất nhiều sau này khi bạn cần lấy nó, so sánh nó hoặc sử dụng nó trong tính toán. Một quyết định quan trọng khác là cách bạn chọn xử lý múi giờ . Tôi muốn lưu trữ mọi thứ theo UTC và xử lý mọi thứ bù lệch múi giờ trên giao diện người dùng, khi thông tin được hiển thị cho người dùng. Điều này giúp mọi thứ nhất quán và tôi không phải lo lắng về việc liệu hàng có được chèn vào lúc 6 giờ tối hay không dựa trên thời gian trên máy tính của người dùng, thời gian trình duyệt của người dùng, thời gian của cơ sở dữ liệu của tôi hoặc thời gian của máy chủ.

  • Bao gồm một ID lĩnh vực đó là duy nhất cho hàng trong mọi bảng. Cách dễ nhất để làm điều này là sử dụng auto_increment (mysql) hoặc identity(1,1) (máy chủ sql) để cơ sở dữ liệu theo dõi nó cho bạn. Các giá trị này có thể được đặt lại hoặc gửi lại nếu bạn cần.

  • Tìm hiểu cách sử dụng chuẩn hóa .

  • Tìm hiểu những gì giao dịch làm và tại sao chúng quan trọng ... ngay cả khi bạn không sử dụng chúng.

  • Tìm hiểu về các loại liên kết khác nhau . Đây là một trong những giải thích tốt nhất Tôi đã từng thấy. Điều chính cần chú ý là nếu phép nối phải là phép nối bên ngoài hay bên trong.

  • Tìm hiểu về SQL Injection và quan trọng hơn, cách thức để ngăn chặn nó (liên kết đó dành cho PHP).

  • Nếu bạn đang sử dụng PHP, không sử dụng mysql_ cũ lớp. Thay vào đó, hãy sử dụng PDO hoặc MySQLi_ . Thông tin ...

  • Điều quan trọng về cơ sở dữ liệu là tính toàn vẹn, xác thực và khử trùng của dữ liệu . Người dùng sẽ muốn đưa tất cả các loại dữ liệu cẩu thả, bẩn thỉu vào các bảng của bạn. Nó là MO hay Missouri? Nữ, F, nữ, con gái, hay có? Mức lương 15,00 một giờ, 50k hàng năm, hay 3.000 một phiếu lương? Đó là ngày 31 tháng 12 năm 2013, ngày 31 tháng 12 năm 2013, ngày 31 tháng 12 năm 2013, ngày 31 tháng 12 năm 2013 hay ngày ba mươi tháng mười hai hai nghìn mười ba?

  • Quyết định xem bạn có muốn cho phép NULL không hay không. Nó làm cho mọi thứ phức tạp hơn vì logic ba trạng thái và bạn sẽ cần phải kiểm tra nó sau. Một số người quyết định chỉ sử dụng một chuỗi rỗng để thay thế. KHÔNG ĐỦ là một trạng thái nhiều hơn là một giá trị thực và nó có nghĩa là không xác định hoặc không xác định - giá trị có thể là bất kỳ thứ gì. Tôi sử dụng null bởi vì một chuỗi trống đôi khi là một giá trị hợp lệ cho một trường. Ví dụ:đặt Middle_Initial bằng một chuỗi rỗng có thể có nghĩa là người đó không có chữ cái đầu ở giữa hoặc có thể có nghĩa là bạn không biết nó là gì. Đối với tôi, những điều này là khác nhau. Đối với những người khác, sự khác biệt không quan trọng. Chỉ cần xem xét các số ... 0 có phải là sames là ẩn số không?

  • Nếu không có gì khác, chỉ cần nhất quán.



  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Làm cách nào để chọn số lượng với trình tạo truy vấn thông thạo của Laravel?

  2. cách thay đổi thời gian chờ cho các kết nối liên tục mysql

  3. Tại sao Entity Framework lại tạo ra các truy vấn SQL lồng nhau?

  4. Khi tôi chạy chương trình JPA không tạo bảng trong MySQL

  5. Hoạt động giống như trục xoay MySQL để nhận phân tích phần trăm tổng số sự kiện mỗi ngày cho mỗi loại sự kiện