programming

Mối quan hệ hùng hồn trong Laravel là gì?

Các mô hình và mối quan hệ của chúng là trung tâm của Laravel Eloquent. Nếu họ gây khó khăn cho bạn hoặc bạn không thể tìm thấy hướng dẫn đơn giản, thân thiện và đầy đủ, hãy bắt đầu tại đây

Ngồi ở phía bên kia của bài báo lập trình của họ, người viết rất dễ giả vờ hoặc thổi phồng hào quang chuyên môn/uy tín mà nền tảng cung cấp. Nhưng thành thật mà nói - tôi đã có một khoảng thời gian cực kỳ khó khăn khi học Laravel, nếu chỉ vì nó là full-stack framework đầu tiên của tôi. Một lý do là tôi không sử dụng nó tại nơi làm việc và khám phá nó vì tò mò; . Tôi phải làm điều này 5-6 lần trước khi nó bắt đầu có ý nghĩa với tôi [tất nhiên, tài liệu không giúp được gì]

Nhưng điều vẫn không có ý nghĩa là Eloquent. Hoặc ít nhất, các mối quan hệ giữa các mô hình [vì Eloquent quá lớn để tìm hiểu hoàn toàn]. Các ví dụ mô hình hóa các tác giả và bài đăng trên blog là một trò đùa vì các dự án thực tế phức tạp hơn nhiều; . Hoặc ngay cả khi tôi bắt gặp một bài báo/tài nguyên hữu ích nào đó, nhưng lời giải thích quá tệ hoặc quá thiếu đến mức nó chẳng có tác dụng gì

[Nhân tiện, trước đây tôi đã từng bị tấn công vì tấn công tài liệu chính thức, vì vậy nếu bạn cũng có ý kiến ​​tương tự, thì đây là câu trả lời tiêu chuẩn của tôi. hãy xem tài liệu Django và sau đó nói chuyện với tôi. ]

Cuối cùng, từng chút một, nó đã đến với nhau và có ý nghĩa. Cuối cùng tôi đã có thể lập mô hình dự án đúng cách và sử dụng các mô hình một cách thoải mái. Sau đó, một ngày nọ, tôi bắt gặp một số thủ thuật Bộ sưu tập gọn gàng giúp công việc này trở nên thú vị hơn. Trong bài viết này, tôi dự định sẽ đề cập đến tất cả, bắt đầu từ những điều cơ bản nhất và sau đó đề cập đến tất cả các trường hợp sử dụng có thể xảy ra mà bạn sẽ gặp phải trong các dự án thực tế.

Tại sao mối quan hệ mô hình Eloquent khó khăn?

Đáng buồn thay, tôi gặp quá nhiều nhà phát triển Laravel không hiểu đúng về các mô hình

Nhưng tại sao?

Thậm chí ngày nay, khi có sự bùng nổ các khóa học, bài báo và video về Laravel, thì sự hiểu biết tổng thể vẫn còn kém. Tôi nghĩ đó là một điểm quan trọng và đáng để suy ngẫm

Nếu bạn hỏi tôi, tôi sẽ nói rằng các mối quan hệ trong mô hình Eloquent không khó chút nào. Ít nhất là khi nhìn từ góc độ của định nghĩa “cứng”. Di chuyển lược đồ trực tiếp là khó khăn; . So với những điều này, việc học và sử dụng ORM. . . tốt, điều đó không thể khó. 🤭🤭

Điều thực sự xảy ra là các nhà phát triển PHP đang học Laravel cảm thấy khó khăn với Eloquent. Đó là vấn đề cơ bản thực sự, và theo tôi, có một số yếu tố góp phần vào vấn đề này [cảnh báo quan điểm gay gắt, không phổ biến. ]

  • Trước Laravel, hầu hết các nhà phát triển PHP đều được tiếp xúc với một framework là CodeIgniter [nhân tiện, nó vẫn còn tồn tại, ngay cả khi nó trở nên giống Laravel/CakePHP hơn]. Trong cộng đồng CodeIgniter cũ hơn [nếu có], “phương pháp hay nhất” là gắn trực tiếp các truy vấn SQL vào nơi cần thiết. Và mặc dù ngày nay chúng ta có CodeIgniter mới, những thói quen vẫn tiếp diễn. Kết quả là khi học Laravel, ý tưởng về ORM hoàn toàn mới đối với các nhà phát triển PHP
  • Loại bỏ một tỷ lệ rất nhỏ PHP tiếp xúc với các framework như Yii, CakePHP, v.v. , phần còn lại được sử dụng để làm việc trong lõi PHP hoặc trong một môi trường như WordPress. Và một lần nữa, tư duy dựa trên OOP không tồn tại, do đó, khung, bộ chứa dịch vụ, mẫu thiết kế, ORM. . . đây là những khái niệm xa lạ
  • Có rất ít hoặc không có khái niệm học liên tục trong thế giới PHP. Nhà phát triển trung bình hài lòng khi làm việc với các thiết lập một máy chủ bằng cách sử dụng cơ sở dữ liệu quan hệ và đưa ra các truy vấn được viết dưới dạng chuỗi. Lập trình không đồng bộ, ổ cắm web, HTTP 2/3, Linux [quên Docker], thử nghiệm đơn vị, Thiết kế hướng tên miền - đây đều là những ý tưởng xa lạ đối với phần lớn các nhà phát triển PHP. Kết quả là, việc đọc một cái gì đó mới và đầy thách thức, đến mức người ta cảm thấy thoải mái, không xảy ra khi gặp phải Eloquent
  • Sự hiểu biết tổng thể về cơ sở dữ liệu và mô hình hóa cũng kém. Vì thiết kế cơ sở dữ liệu được liên kết trực tiếp, không thể tách rời với các mô hình Eloquent, nên nó sẽ nâng mức độ khó lên cao hơn

Tôi không có ý gay gắt và khái quát hóa toàn cầu — cũng có các nhà phát triển PHP xuất sắc và nhiều người trong số họ, nhưng tỷ lệ chung của họ rất thấp

Nếu bạn đang đọc điều này, điều đó có nghĩa là bạn đã vượt qua tất cả những rào cản này, bắt gặp Laravel và gặp rắc rối với Eloquent

Xin chúc mừng. 👏

Bạn đã gần tới. Tất cả các khối xây dựng đã sẵn sàng và chúng ta chỉ cần xem qua chúng theo thứ tự và chi tiết phù hợp. Nói cách khác, hãy bắt đầu ở cấp cơ sở dữ liệu

mô hình cơ sở dữ liệu. Mối quan hệ và Cardinality

Để đơn giản, hãy giả sử rằng chúng ta chỉ làm việc với cơ sở dữ liệu quan hệ trong suốt bài viết này. Một lý do là ORM ban đầu được phát triển cho cơ sở dữ liệu quan hệ;

Mô hình dữ liệu

Trước tiên, hãy hiểu rõ hơn về các mô hình dữ liệu. Ý tưởng về một mô hình [hay chính xác hơn là mô hình dữ liệu], xuất phát từ cơ sở dữ liệu. Không có cơ sở dữ liệu, không có dữ liệu và do đó, không có mô hình dữ liệu. Và một mô hình dữ liệu là gì? . Ví dụ: trong một cửa hàng thương mại điện tử, bạn có thể lưu trữ mọi thứ trong một bảng khổng lồ [thực tế TUYỆT VỜI, nhưng thật đáng buồn, không phải là hiếm trong thế giới PHP]; . Bạn cũng có thể chia dữ liệu thành 20 bảng chính và 16 bảng kết nối;

Ngoài ra, lưu ý rằng cách cấu trúc dữ liệu trong cơ sở dữ liệu không nhất thiết phải khớp 100% với cách dữ liệu được sắp xếp trong ORM của khung. Tuy nhiên, nỗ lực là luôn giữ mọi thứ gần nhất có thể để chúng tôi không còn một điều gì phải lưu tâm khi phát triển

hồng y

Chúng ta cũng hãy hiểu thuật ngữ này một cách nhanh chóng. bản chất. Nó chỉ đề cập đến "đếm", nói một cách lỏng lẻo. Vì vậy, 1, 2, 3. . . tất cả có thể là cardinality của một cái gì đó. kết thúc câu chuyện. Hãy tiếp tục di chuyển

Các mối quan hệ

Bây giờ, bất cứ khi nào chúng tôi lưu trữ dữ liệu trong bất kỳ loại hệ thống nào, sẽ có nhiều cách để các điểm dữ liệu có thể liên quan với nhau. Tôi biết điều này nghe có vẻ trừu tượng và nhàm chán, nhưng hãy kiên nhẫn với tôi một chút. Các cách kết nối các mục dữ liệu khác nhau được gọi là mối quan hệ. Trước tiên hãy xem một số ví dụ phi cơ sở dữ liệu để chúng tôi tin rằng chúng tôi hoàn toàn hiểu ý tưởng

  • Nếu chúng ta lưu trữ mọi thứ trong một mảng, một mối quan hệ có thể xảy ra là. mục dữ liệu tiếp theo có chỉ số lớn hơn chỉ mục trước đó bởi 
    class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
    3
  • Nếu chúng tôi lưu trữ dữ liệu trong cây nhị phân, một mối quan hệ có thể xảy ra là cây con bên trái luôn có giá trị nhỏ hơn nút cha [nếu chúng tôi chọn duy trì cây theo cách đó]
  • Nếu chúng ta lưu trữ dữ liệu dưới dạng một mảng gồm các mảng có độ dài bằng nhau, chúng ta có thể bắt chước một ma trận và sau đó các thuộc tính của nó trở thành mối quan hệ cho dữ liệu của chúng ta

Vì vậy, chúng tôi thấy rằng từ "mối quan hệ", trong ngữ cảnh của dữ liệu, không có ý nghĩa cố định. Trên thực tế, nếu hai người đang xem cùng một dữ liệu, họ có thể xác định hai mối quan hệ dữ liệu rất khác nhau [xin chào, số liệu thống kê. ] và cả hai đều có thể hợp lệ

Cơ sở dữ liệu quan hệ

Dựa trên tất cả các thuật ngữ mà chúng ta đã thảo luận cho đến bây giờ, cuối cùng chúng ta cũng có thể nói về một thứ có liên kết trực tiếp đến các mô hình trong khung web [Laravel] - cơ sở dữ liệu quan hệ. Đối với hầu hết chúng ta, cơ sở dữ liệu chính được sử dụng là MySQL, MariaDB, PostgreSQL, MSSQL, SQL Server, SQLite hoặc thứ gì đó tương tự. Chúng ta cũng có thể mơ hồ biết rằng chúng được gọi là RDBMS nhưng hầu hết chúng ta đã quên ý nghĩa thực sự của nó và tại sao nó lại quan trọng

“R” trong RDBMS là viết tắt của Relational, tất nhiên. Đây không phải là một thuật ngữ được lựa chọn tùy tiện; . Trên thực tế, "mối quan hệ" ở đây có ý nghĩa toán học nghiêm ngặt và mặc dù không nhà phát triển nào cần bận tâm về điều đó, nhưng sẽ hữu ích khi biết rằng có một nền tảng toán học chặt chẽ bên dưới các loại cơ sở dữ liệu này

Khám phá các tài nguyên này để tìm hiểu SQL và NoSQL

Được rồi, theo kinh nghiệm chúng tôi biết rằng dữ liệu trong RDBMS được lưu trữ dưới dạng bảng. Vậy thì, các mối quan hệ ở đâu?

Các loại quan hệ trong RDBMS

Đây có lẽ là phần quan trọng nhất trong toàn bộ chủ đề về Laravel và các mối quan hệ mô hình. Nếu bạn không hiểu điều này, Eloquent sẽ không bao giờ có ý nghĩa, vì vậy hãy chú ý trong vài phút tới [nó thậm chí không khó lắm đâu]

RDBMS cho phép chúng tôi có mối quan hệ giữa dữ liệu - ở cấp cơ sở dữ liệu. Điều này có nghĩa là những mối quan hệ này không phi thực tế/tưởng tượng/chủ quan và có thể được tạo ra hoặc suy luận bởi những người khác nhau với cùng một kết quả

Đồng thời, có một số khả năng/công cụ trong RDBMS cho phép chúng tôi tạo và thực thi các mối quan hệ này, chẳng hạn như

  • Khóa chính
  • Khóa ngoại
  • Hạn chế

Tôi không muốn bài viết này trở thành một khóa học về cơ sở dữ liệu, vì vậy tôi sẽ cho rằng bạn biết những khái niệm này là gì. Nếu không, hoặc trong trường hợp bạn cảm thấy không tự tin, tôi khuyên bạn nên xem video thân thiện này [vui lòng khám phá toàn bộ chuỗi video]

Khi điều đó xảy ra, các mối quan hệ kiểu RDBMS này cũng là những mối quan hệ phổ biến nhất xảy ra trong các ứng dụng trong thế giới thực [không phải lúc nào cũng vậy, vì mạng xã hội được mô hình hóa tốt nhất dưới dạng biểu đồ chứ không phải dưới dạng tập hợp các bảng]. Vì vậy, chúng ta hãy xem xét từng cái một và cũng cố gắng hiểu chúng có thể hữu ích ở đâu

Mối quan hệ một đối một

Trong hầu hết mọi ứng dụng web đều có tài khoản người dùng. Ngoài ra, những điều sau đây là đúng [nói chung] về người dùng và tài khoản

  • Một người dùng chỉ có thể có một tài khoản
  • Một tài khoản chỉ có thể được sở hữu bởi một người dùng

Có, chúng tôi có thể lập luận rằng một người có thể đăng ký bằng một email khác và do đó tạo hai tài khoản, nhưng từ góc độ của ứng dụng web, đó là hai người khác nhau với hai tài khoản khác nhau. Ví dụ: ứng dụng sẽ không hiển thị dữ liệu của một tài khoản trong một tài khoản khác

Ý nghĩa của việc chia tóc này là gì — nếu bạn gặp tình huống như thế này trong ứng dụng của mình và bạn đang sử dụng cơ sở dữ liệu quan hệ, bạn cần thiết kế nó dưới dạng mối quan hệ một đối một. Lưu ý rằng không ai ép buộc bạn một cách giả tạo — có một tình huống rõ ràng trong lĩnh vực kinh doanh và tình cờ bạn đang sử dụng cơ sở dữ liệu quan hệ. . . chỉ khi cả hai điều kiện này được thỏa mãn, bạn mới đạt được mối quan hệ một đối một

Đối với ví dụ này [người dùng và tài khoản], đây là cách chúng tôi có thể triển khai mối quan hệ này khi tạo lược đồ

CREATE TABLE users[
    id INT NOT NULL AUTO_INCREMENT,
    email VARCHAR[100] NOT NULL,
    password VARCHAR[100] NOT NULL,
    PRIMARY KEY[id]
];

CREATE TABLE accounts[
    id INT NOT NULL AUTO_INCREMENT,
    role VARCHAR[50] NOT NULL,
    PRIMARY KEY[id],
    FOREIGN KEY[id] REFERENCES users[id]
];

Chú ý mánh khóe ở đây? . Thuộc tính khóa ngoại liên kết nó với bảng 

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
6 [tất nhiên 🙄] trong khi thuộc tính khóa chính làm cho cột 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
5 trở thành duy nhất — một mối quan hệ một đối một thực sự

Cấp, độ trung thực của mối quan hệ này không được đảm bảo. Chẳng hạn, không gì có thể ngăn tôi thêm 200 người dùng mới mà không cần thêm một mục nhập nào vào bảng 

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
4. Nếu tôi làm thế, tôi sẽ kết thúc với mối quan hệ một mất một còn. 🤭🤭 Nhưng trong giới hạn của cấu trúc thuần túy, đó là điều tốt nhất chúng ta có thể làm. Nếu chúng tôi muốn ngăn thêm người dùng mà không có tài khoản, chúng tôi cần trợ giúp từ một số loại logic lập trình, dưới dạng trình kích hoạt cơ sở dữ liệu hoặc xác thực do Laravel thực thi

Nếu bạn đang bắt đầu căng thẳng, tôi có một số lời khuyên rất hữu ích

  • Chậm lại đi. Chậm như bạn cần. Thay vì cố gắng hoàn thành bài viết này và 15 bài viết khác mà bạn đã đánh dấu cho ngày hôm nay, hãy tập trung vào bài viết này. Hãy để nó mất 3, 4, 5 ngày nếu đó là những gì nó cần - mục tiêu của bạn là loại bỏ vĩnh viễn các mối quan hệ của người mẫu Eloquent khỏi danh sách của bạn. Trước đây bạn đã nhảy từ bài báo này sang bài viết khác, lãng phí hàng trăm giờ nhưng không giúp được gì. Vì vậy, hãy làm điều gì đó khác biệt lần này. 😇
  • Mặc dù bài viết này nói về Laravel Eloquent, nhưng tất cả những điều đó sẽ đến muộn hơn nhiều. Nền tảng của tất cả là lược đồ cơ sở dữ liệu, vì vậy chúng ta nên tập trung vào việc đạt được điều đó trước tiên. Nếu bạn không thể làm việc thuần túy ở cấp độ cơ sở dữ liệu [giả sử không có khung nào trên thế giới], thì các mô hình và mối quan hệ sẽ không bao giờ có ý nghĩa đầy đủ. Vì vậy, hãy tạm quên Laravel đi. Hoàn toàn. Hiện tại chúng tôi chỉ nói về và thiết kế cơ sở dữ liệu. Vâng, thỉnh thoảng tôi sẽ tạo các tài liệu tham khảo về Laravel, nhưng công việc của bạn là bỏ qua chúng hoàn toàn nếu chúng làm phức tạp bức tranh cho bạn
  • Sau này, hãy đọc thêm một chút về cơ sở dữ liệu và những gì chúng cung cấp. Chỉ mục, hiệu suất, trình kích hoạt, cấu trúc dữ liệu cơ bản và hành vi của chúng, bộ nhớ đệm, mối quan hệ trong MongoDB. . . bất kỳ chủ đề tiếp tuyến nào bạn có thể đề cập sẽ giúp ích cho bạn với tư cách là một kỹ sư. Hãy nhớ rằng, các mô hình khung chỉ là vỏ ma;

Mối quan hệ một-nhiều

Tôi không chắc liệu bạn có nhận ra điều này hay không, nhưng đây là kiểu quan hệ mà tất cả chúng ta đều tạo ra bằng trực giác trong công việc hàng ngày của mình. Ví dụ: khi chúng tôi tạo bảng 

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
9 [ví dụ giả định], để lưu trữ khóa ngoại cho bảng 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
6, chúng tôi tạo mối quan hệ một-nhiều giữa người dùng và đơn đặt hàng. Tại sao vậy? . một người dùng được phép có nhiều hơn một đơn đặt hàng, đó gần như là cách hoạt động của tất cả thương mại điện tử. Và nhìn từ phía ngược lại, mối quan hệ nói rằng một đơn đặt hàng chỉ có thể thuộc về một người dùng, điều này cũng rất có ý nghĩa

Trong mô hình hóa dữ liệu, sách RDBMS và tài liệu hệ thống, tình huống này được biểu diễn dưới dạng biểu đồ như sau

Chú ý ba dòng tạo thành một cây đinh ba các loại?

Nhân tiện, những số lượng “nhiều” và “một” mà chúng ta gặp lặp đi lặp lại được gọi là Số lượng của một mối quan hệ [bạn có nhớ từ này trong phần trước không?]. Một lần nữa, đối với bài viết này, thuật ngữ này không được sử dụng, nhưng nó giúp biết khái niệm này trong trường hợp nó xuất hiện trong các cuộc phỏng vấn hoặc đọc thêm

Đơn giản, phải không? . Trên thực tế, nó đơn giản hơn nhiều so với trường hợp quan hệ một đối một.

CREATE TABLE users[ 
    id INT NOT NULL AUTO_INCREMENT, 
    email VARCHAR[100] NOT NULL, 
    password VARCHAR[100] NOT NULL, 
    PRIMARY KEY[id] 
];

CREATE TABLE orders[ 
    id INT NOT NULL AUTO_INCREMENT, 
    user_id INT NOT NULL, 
    description VARCHAR[50] NOT NULL, 
    PRIMARY KEY[id], 
    FOREIGN KEY[user_id] REFERENCES users[id] 
];

Bảng 

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
9 lưu trữ ID người dùng cho mỗi đơn đặt hàng. Vì không có ràng buộc [hạn chế] rằng ID người dùng trong bảng 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
9 phải là duy nhất, điều đó có nghĩa là chúng ta có thể lặp lại một ID nhiều lần. Đây là thứ tạo ra mối quan hệ một-nhiều, chứ không phải một số phép thuật phức tạp ẩn bên dưới. ID người dùng được lưu trữ một cách ngớ ngẩn trong bảng 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
9 và SQL không có bất kỳ khái niệm nào về một-nhiều, một-một, v.v. Nhưng khi lưu trữ dữ liệu theo cách này, chúng ta có thể nghĩ rằng có mối quan hệ một-nhiều

Hy vọng, nó có ý nghĩa bây giờ. Hoặc ít nhất, có ý nghĩa hơn trước. 😅 Hãy nhớ rằng giống như bất kỳ điều gì khác, đây chỉ là vấn đề thực hành và một khi bạn đã thực hiện điều này 4-5 lần trong các tình huống thực tế, bạn thậm chí sẽ không nghĩ về nó nữa

Mối quan hệ nhiều-nhiều

Loại quan hệ tiếp theo phát sinh trong thực tế là cái gọi là quan hệ nhiều-nhiều. Một lần nữa, trước khi lo lắng về các khung hoặc thậm chí đi sâu vào cơ sở dữ liệu, hãy nghĩ về một tương tự trong thế giới thực. sách và tác giả. Hãy nghĩ về tác giả yêu thích của bạn; . Vì vậy, một tác giả có thể viết nhiều cuốn sách và nhiều tác giả có thể viết một cuốn sách. Giữa hai thực thể [sách và tác giả], điều này tạo thành mối quan hệ nhiều-nhiều

Bây giờ, với điều kiện là bạn rất khó có thể tạo một ứng dụng trong thế giới thực liên quan đến thư viện hoặc sách và tác giả, vì vậy hãy nghĩ thêm một số ví dụ. Trong cài đặt B2B, nhà sản xuất đặt hàng các mặt hàng từ nhà cung cấp và lần lượt nhận được hóa đơn. Hóa đơn sẽ chứa một số mục hàng, mỗi mục liệt kê số lượng và mặt hàng được cung cấp; . Trong tình huống này, các mặt hàng và hóa đơn có mối quan hệ nhiều-nhiều [hãy suy nghĩ và thuyết phục bản thân]. Trong một hệ thống quản lý đội xe, phương tiện và tài xế sẽ có mối quan hệ tương tự nhau. Trong trang web thương mại điện tử, người dùng và sản phẩm có thể có mối quan hệ nhiều-nhiều nếu chúng tôi xem xét các chức năng như danh sách yêu thích hoặc mong muốn

Đủ công bằng, bây giờ làm cách nào để tạo mối quan hệ nhiều-nhiều này trong SQL? . Tuy nhiên, chúng tôi gặp vấn đề lớn nếu chúng tôi cố gắng làm điều này. Hãy xem ví dụ này trong đó những cuốn sách mà tác giả được cho là có mối quan hệ nhiều-nhiều

Thoạt nhìn, mọi thứ có vẻ ổn — sách được ánh xạ tới các tác giả một cách chính xác theo kiểu nhiều-nhiều. Nhưng hãy nhìn kỹ vào dữ liệu bảng 

CREATE TABLE users[
    id INT NOT NULL AUTO_INCREMENT,
    email VARCHAR[100] NOT NULL,
    password VARCHAR[100] NOT NULL,
    PRIMARY KEY[id]
];

CREATE TABLE accounts[
    id INT NOT NULL AUTO_INCREMENT,
    role VARCHAR[50] NOT NULL,
    PRIMARY KEY[id],
    FOREIGN KEY[id] REFERENCES users[id]
];
34. id cuốn sách 12 và 13 đều được viết bởi Peter M. [id tác giả 2], do đó chúng tôi không có lựa chọn nào khác ngoài việc lặp lại các mục. Hiện tại, bảng 
CREATE TABLE users[
    id INT NOT NULL AUTO_INCREMENT,
    email VARCHAR[100] NOT NULL,
    password VARCHAR[100] NOT NULL,
    PRIMARY KEY[id]
];

CREATE TABLE accounts[
    id INT NOT NULL AUTO_INCREMENT,
    role VARCHAR[50] NOT NULL,
    PRIMARY KEY[id],
    FOREIGN KEY[id] REFERENCES users[id]
];
34 không chỉ có vấn đề về tính toàn vẹn dữ liệu [chuẩn hóa đúng cách và tất cả những thứ đó], các giá trị trong cột 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
5 hiện đang lặp lại. Điều này có nghĩa là trong thiết kế mà chúng tôi đã chọn, không thể có cột khóa chính [vì khóa chính không thể có giá trị trùng lặp] và mọi thứ sẽ bị phá vỡ

Rõ ràng, chúng ta cần một cách mới để làm điều này, và may mắn thay, vấn đề này đã được giải quyết. Vì việc lưu trữ khóa ngoại trực tiếp vào cả hai bảng sẽ làm hỏng mọi thứ, nên cách đúng đắn để tạo mối quan hệ nhiều-nhiều trong RDBMS là tạo một cái gọi là “bảng nối”. Về cơ bản, ý tưởng là để hai bảng ban đầu không bị xáo trộn và tạo một bảng thứ ba để thể hiện ánh xạ nhiều-nhiều

Hãy làm lại ví dụ không thành công để chứa một bảng tham gia

Lưu ý rằng đã có những thay đổi mạnh mẽ

  • Số cột trong bảng 
    CREATE TABLE users[
    id INT NOT NULL AUTO_INCREMENT,
    email VARCHAR[100] NOT NULL,
    password VARCHAR[100] NOT NULL,
    PRIMARY KEY[id]
];

CREATE TABLE accounts[
    id INT NOT NULL AUTO_INCREMENT,
    role VARCHAR[50] NOT NULL,
    PRIMARY KEY[id],
    FOREIGN KEY[id] REFERENCES users[id]
];
    34 bị giảm
  • Số cột trong bảng 
    CREATE TABLE users[
    id INT NOT NULL AUTO_INCREMENT,
    email VARCHAR[100] NOT NULL,
    password VARCHAR[100] NOT NULL,
    PRIMARY KEY[id]
];

CREATE TABLE accounts[
    id INT NOT NULL AUTO_INCREMENT,
    role VARCHAR[50] NOT NULL,
    PRIMARY KEY[id],
    FOREIGN KEY[id] REFERENCES users[id]
];
    38 bị giảm
  • Số lượng hàng trong bảng 
    CREATE TABLE users[
    id INT NOT NULL AUTO_INCREMENT,
    email VARCHAR[100] NOT NULL,
    password VARCHAR[100] NOT NULL,
    PRIMARY KEY[id]
];

CREATE TABLE accounts[
    id INT NOT NULL AUTO_INCREMENT,
    role VARCHAR[50] NOT NULL,
    PRIMARY KEY[id],
    FOREIGN KEY[id] REFERENCES users[id]
];
    34 giảm đi vì không cần lặp lại nữa
  • Một bảng mới có tên là 
    CREATE TABLE users[
    id INT NOT NULL AUTO_INCREMENT,
    email VARCHAR[100] NOT NULL,
    password VARCHAR[100] NOT NULL,
    PRIMARY KEY[id]
];

CREATE TABLE accounts[
    id INT NOT NULL AUTO_INCREMENT,
    role VARCHAR[50] NOT NULL,
    PRIMARY KEY[id],
    FOREIGN KEY[id] REFERENCES users[id]
];
    90 đã xuất hiện, chứa thông tin về id tác giả nào được kết nối với id cuốn sách nào. Chúng ta có thể đặt tên bất kỳ cho bảng nối, nhưng theo quy ước, đó là kết quả của việc nối hai bảng mà nó đại diện, sử dụng dấu gạch dưới

Bảng tham gia không có khóa chính và trong hầu hết các trường hợp chỉ chứa hai cột — ID từ hai bảng. Gần như là chúng ta đã xóa các cột khóa ngoại khỏi ví dụ trước đó và dán chúng vào bảng mới này. Vì không có khóa chính nên có thể có nhiều lần lặp lại cần thiết để ghi lại tất cả các mối quan hệ

Bây giờ, chúng ta có thể thấy bằng mắt cách bảng tham gia hiển thị rõ ràng các mối quan hệ, nhưng làm cách nào để chúng ta truy cập chúng trong các ứng dụng của mình? . Đây không phải là khóa học về truy vấn SQL nên tôi sẽ không đi sâu vào nó nhưng ý tưởng là nếu bạn muốn tất cả các cuốn sách của một tác giả cụ thể trong một truy vấn hiệu quả, thì bạn nối SQL các bảng theo cùng một thứ tự –> . Các bảng 

CREATE TABLE users[
    id INT NOT NULL AUTO_INCREMENT,
    email VARCHAR[100] NOT NULL,
    password VARCHAR[100] NOT NULL,
    PRIMARY KEY[id]
];

CREATE TABLE accounts[
    id INT NOT NULL AUTO_INCREMENT,
    role VARCHAR[50] NOT NULL,
    PRIMARY KEY[id],
    FOREIGN KEY[id] REFERENCES users[id]
];
34 và 
CREATE TABLE users[
    id INT NOT NULL AUTO_INCREMENT,
    email VARCHAR[100] NOT NULL,
    password VARCHAR[100] NOT NULL,
    PRIMARY KEY[id]
];

CREATE TABLE accounts[
    id INT NOT NULL AUTO_INCREMENT,
    role VARCHAR[50] NOT NULL,
    PRIMARY KEY[id],
    FOREIGN KEY[id] REFERENCES users[id]
];
90 được nối tương ứng trên các cột 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
5 và 
CREATE TABLE users[
    id INT NOT NULL AUTO_INCREMENT,
    email VARCHAR[100] NOT NULL,
    password VARCHAR[100] NOT NULL,
    PRIMARY KEY[id]
];

CREATE TABLE accounts[
    id INT NOT NULL AUTO_INCREMENT,
    role VARCHAR[50] NOT NULL,
    PRIMARY KEY[id],
    FOREIGN KEY[id] REFERENCES users[id]
];
97, trong khi các bảng 
CREATE TABLE users[
    id INT NOT NULL AUTO_INCREMENT,
    email VARCHAR[100] NOT NULL,
    password VARCHAR[100] NOT NULL,
    PRIMARY KEY[id]
];

CREATE TABLE accounts[
    id INT NOT NULL AUTO_INCREMENT,
    role VARCHAR[50] NOT NULL,
    PRIMARY KEY[id],
    FOREIGN KEY[id] REFERENCES users[id]
];
90 và 
CREATE TABLE users[
    id INT NOT NULL AUTO_INCREMENT,
    email VARCHAR[100] NOT NULL,
    password VARCHAR[100] NOT NULL,
    PRIMARY KEY[id]
];

CREATE TABLE accounts[
    id INT NOT NULL AUTO_INCREMENT,
    role VARCHAR[50] NOT NULL,
    PRIMARY KEY[id],
    FOREIGN KEY[id] REFERENCES users[id]
];
38 được nối tương ứng trên các cột 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
90 và 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
5

Mệt mỏi, vâng. Nhưng hãy nhìn vào mặt tích cực — chúng tôi đã hoàn thành tất cả lý thuyết/nền tảng cần thiết mà chúng tôi cần làm trước khi giải quyết các mô hình Eloquent. Và để tôi nhắc bạn rằng tất cả những thứ này không phải là tùy chọn. Không biết thiết kế cơ sở dữ liệu sẽ khiến bạn mãi mãi ở trong vùng đất nhầm lẫn Eloquent. Hơn nữa, bất cứ điều gì Eloquent làm hoặc cố gắng làm đều phản ánh hoàn hảo các chi tiết cấp cơ sở dữ liệu này, vì vậy thật dễ hiểu tại sao cố gắng học Eloquent trong khi chạy trốn khỏi RDBMS là một bài tập vô ích

Tạo mối quan hệ mô hình trong Laravel Eloquent

Cuối cùng, sau một chặng đường vòng kéo dài khoảng 70.000 dặm, chúng ta đã đạt đến điểm mà chúng ta có thể nói về Eloquent, các mô hình của nó và cách tạo/sử dụng chúng. Bây giờ, chúng ta đã học trong phần trước của bài viết rằng mọi thứ đều bắt đầu với cơ sở dữ liệu và cách bạn lập mô hình dữ liệu của mình. Điều này khiến tôi nhận ra rằng tôi nên sử dụng một ví dụ hoàn chỉnh duy nhất để bắt đầu một dự án mới. Đồng thời, tôi muốn ví dụ này là thế giới thực, không phải về blog và tác giả hay sách và giá sách [cũng là thế giới thực, nhưng đã bị loại bỏ]

Hãy tưởng tượng một cửa hàng bán đồ chơi mềm. Cũng giả sử rằng chúng tôi đã được cung cấp tài liệu yêu cầu, từ đó chúng tôi có thể xác định bốn thực thể này trong hệ thống. người dùng, đơn đặt hàng, hóa đơn, mặt hàng, danh mục, danh mục con và giao dịch. Vâng, có thể sẽ phức tạp hơn, nhưng hãy tạm gác vấn đề đó sang một bên và tập trung vào cách chúng tôi chuyển từ tài liệu sang ứng dụng

Khi các thực thể chính trong hệ thống đã được xác định, chúng ta cần nghĩ xem chúng liên quan với nhau như thế nào, xét về mối quan hệ cơ sở dữ liệu mà chúng ta đã thảo luận cho đến nay. Đây là những cái mà tôi có thể nghĩ ra

  • Người dùng và Đơn đặt hàng. Một đến nhiều
  • Đơn đặt hàng và hóa đơn. một đối một. Tôi nhận thấy mối quan hệ này không được cắt và sấy khô và tùy thuộc vào lĩnh vực kinh doanh của bạn, có thể có mối quan hệ một với nhiều, nhiều với một hoặc nhiều với nhiều. Nhưng khi nói đến cửa hàng thương mại điện tử nhỏ, trung bình của bạn, một đơn hàng sẽ chỉ dẫn đến một hóa đơn và ngược lại
  • Đơn đặt hàng và mặt hàng. Nhiều nhiều
  • Hạng mục và Hạng mục. Nhiều đến một. Một lần nữa, điều này không xảy ra ở các trang thương mại điện tử lớn, nhưng chúng tôi có một hoạt động nhỏ
  • Danh mục và Danh mục con. một đến nhiều. Một lần nữa, bạn sẽ tìm thấy hầu hết các ví dụ trong thế giới thực mâu thuẫn với điều này, nhưng này, Eloquent đã đủ khó rồi, vì vậy đừng làm cho mô hình dữ liệu khó hơn
  • Lệnh và Giao dịch. Một đến nhiều. Tôi cũng muốn thêm hai điểm này để chứng minh cho sự lựa chọn của mình. 1] Chúng tôi cũng có thể thêm mối quan hệ giữa Giao dịch và Hóa đơn. Nó chỉ là một quyết định mô hình hóa dữ liệu. 2] Tại sao một đến nhiều ở đây? . Trong trường hợp này, chúng tôi có hai giao dịch được tạo cho đơn đặt hàng đó. Việc chúng tôi có muốn hiển thị các giao dịch không thành công đó hay không là một quyết định kinh doanh, nhưng luôn luôn nên thu thập dữ liệu có giá trị

Có mối quan hệ nào khác không? . Ví dụ: chúng ta có thể nói rằng một người dùng có nhiều giao dịch, vì vậy cần có mối quan hệ giữa chúng. Điều cần nhận ra ở đây là đã có một mối quan hệ gián tiếp. người dùng -> đơn đặt hàng -> giao dịch và nói chung, nó đủ tốt vì RDBMS là những con thú trong việc tham gia các bảng. Thứ hai, tạo mối quan hệ này có nghĩa là thêm một cột 

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
92 vào bảng 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
93. Nếu chúng tôi làm điều này cho mọi mối quan hệ trực tiếp có thể xảy ra, thì chúng tôi sẽ tăng thêm rất nhiều tải cho cơ sở dữ liệu [dưới dạng nhiều bộ nhớ hơn, đặc biệt nếu các UUID đang được sử dụng và duy trì các chỉ mục], xâu chuỗi toàn bộ hệ thống. Chắc chắn rồi, nếu doanh nghiệp nói rằng họ cần dữ liệu giao dịch và cần nó trong vòng 1. 5 giây, chúng tôi có thể quyết định thêm mối quan hệ đó và tăng tốc mọi thứ [sự đánh đổi, sự đánh đổi. . . ]

Và bây giờ, thưa quý vị và các bạn, đã đến lúc viết mã thực sự

Mối quan hệ mô hình Laravel - ví dụ thực tế với mã

Phần tiếp theo của bài viết này là về việc làm bẩn tay — nhưng theo một cách hữu ích. Chúng tôi sẽ chọn các thực thể cơ sở dữ liệu giống như trong ví dụ thương mại điện tử trước đó và chúng tôi sẽ xem cách các mô hình trong Laravel được tạo và kết nối, ngay từ khi cài đặt Laravel

Đương nhiên, tôi cho rằng bạn đã thiết lập môi trường phát triển của mình và bạn biết cách cài đặt và sử dụng Trình soạn thảo để quản lý các phụ thuộc

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
3

Hai lệnh console này cài đặt trình cài đặt Laravel [phần 

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
94 được sử dụng để nâng cấp vì tôi đã cài đặt phiên bản cũ hơn]. Và trong trường hợp bạn tò mò, phiên bản Laravel đã được cài đặt là 8. 5. 9. Bạn có nên hoảng sợ và nâng cấp không? . Một số thứ đã thay đổi và sẽ ảnh hưởng đến bài viết này [chẳng hạn như Model Factory], nhưng tôi nghĩ bạn sẽ có thể chuyển mã

Vì chúng ta đã nghĩ về mô hình dữ liệu và các mối quan hệ của chúng, phần tạo mô hình sẽ không quan trọng. Và bạn cũng sẽ thấy [Bây giờ tôi nghe giống như một bản ghi bị hỏng. ] cách nó phản chiếu lược đồ cơ sở dữ liệu vì nó phụ thuộc 100% vào nó

Nói cách khác, trước tiên chúng ta cần tạo các lần di chuyển [và các tệp mô hình] cho tất cả các mô hình sẽ được áp dụng cho cơ sở dữ liệu. Sau đó, chúng ta có thể làm việc trên các mô hình và giải quyết các mối quan hệ

Vì vậy, chúng ta bắt đầu với mô hình nào? . Trong trường hợp của chúng tôi, điều này có nghĩa là mô hình 

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
95. Vì Laravel cung cấp mô hình này [và không thể hoạt động nếu không có nó 🤣], hãy sửa đổi tệp di chuyển và cũng làm sạch mô hình cho phù hợp với nhu cầu đơn giản của chúng ta

Đây là lớp di chuyển

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}

Vì chúng tôi không thực sự xây dựng một dự án, nên chúng tôi không cần nhập mật khẩu, is_active và tất cả những thứ đó. Bảng 

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
6 của chúng ta sẽ chỉ có hai cột. id và tên của người dùng

Hãy tạo di chuyển cho 

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
97 tiếp theo. Vì Laravel cho phép chúng tôi tạo mô hình thuận tiện trong một lệnh duy nhất, nên chúng tôi sẽ tận dụng điều đó, mặc dù hiện tại chúng tôi sẽ không chạm vào tệp mô hình

CREATE TABLE users[
    id INT NOT NULL AUTO_INCREMENT,
    email VARCHAR[100] NOT NULL,
    password VARCHAR[100] NOT NULL,
    PRIMARY KEY[id]
];

CREATE TABLE accounts[
    id INT NOT NULL AUTO_INCREMENT,
    role VARCHAR[50] NOT NULL,
    PRIMARY KEY[id],
    FOREIGN KEY[id] REFERENCES users[id]
];
3

Và đây là lớp di chuyển

CREATE TABLE users[
    id INT NOT NULL AUTO_INCREMENT,
    email VARCHAR[100] NOT NULL,
    password VARCHAR[100] NOT NULL,
    PRIMARY KEY[id]
];

CREATE TABLE accounts[
    id INT NOT NULL AUTO_INCREMENT,
    role VARCHAR[50] NOT NULL,
    PRIMARY KEY[id],
    FOREIGN KEY[id] REFERENCES users[id]
];
9

Nếu bạn ngạc nhiên khi không có chức năng 

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
98, đừng ngạc nhiên; . Trong quá trình phát triển, bạn sẽ thấy mình bỏ toàn bộ cơ sở dữ liệu và sau đó chạy lại quá trình di chuyển. Nhưng chúng ta lạc đề rồi, vì vậy hãy quay lại và xử lý thực thể tiếp theo. Vì các danh mục phụ có liên quan trực tiếp đến các danh mục, tôi nghĩ bạn nên làm điều đó tiếp theo

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
9

Được rồi, bây giờ hãy điền vào tệp di chuyển

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
3

Như bạn có thể thấy, chúng tôi thêm một cột riêng ở đây, được gọi là 

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
99, cột này sẽ lưu trữ các ID từ bảng 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
30. Không có giải thưởng cho việc đoán, điều này tạo ra mối quan hệ một đến nhiều ở cấp cơ sở dữ liệu

Bây giờ đến lượt các mặt hàng

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
6

Và cuộc di cư

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
7

Nếu bạn cảm thấy mọi thứ nên được làm khác đi, thì tốt thôi. Hai người sẽ hiếm khi đưa ra cùng một lược đồ và kiến ​​trúc. Xin lưu ý một điều, đó là một cách thực hành tốt nhất. Tôi đã lưu giá dưới dạng số nguyên

Tại sao?

Chà, mọi người nhận ra rằng việc xử lý các phép chia float và tất cả đều xấu và dễ bị lỗi ở phía cơ sở dữ liệu, vì vậy họ bắt đầu lưu trữ giá theo đơn vị tiền tệ nhỏ nhất. Ví dụ: nếu chúng tôi đang hoạt động bằng USD, trường giá ở đây sẽ đại diện cho xu. Trong toàn bộ hệ thống, các giá trị và phép tính sẽ được tính bằng xu; . Thông minh nhỉ?

Dù sao, hãy lưu ý rằng một mục được liên kết với một danh mục con trong mối quan hệ nhiều-một. Nó cũng được liên kết với một danh mục. . . gián tiếp thông qua tiểu thể loại của nó. Chúng tôi sẽ thấy các cuộc biểu tình chắc chắn của tất cả các môn thể dục dụng cụ này, nhưng hiện tại, chúng tôi cần đánh giá cao các khái niệm và đảm bảo rằng chúng tôi rõ ràng 100%

Tiếp theo là mô hình 

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
31 và quá trình di chuyển của nó

CREATE TABLE users[ 
    id INT NOT NULL AUTO_INCREMENT, 
    email VARCHAR[100] NOT NULL, 
    password VARCHAR[100] NOT NULL, 
    PRIMARY KEY[id] 
];

CREATE TABLE orders[ 
    id INT NOT NULL AUTO_INCREMENT, 
    user_id INT NOT NULL, 
    description VARCHAR[50] NOT NULL, 
    PRIMARY KEY[id], 
    FOREIGN KEY[user_id] REFERENCES users[id] 
];
0

Để cho ngắn gọn, tôi sẽ chỉ bao gồm một số trường quan trọng trong quá trình di chuyển. Ý tôi là, chi tiết của một đơn đặt hàng có thể chứa rất nhiều thứ, nhưng chúng tôi sẽ giới hạn chúng ở một vài thứ để chúng tôi có thể tập trung vào khái niệm về mối quan hệ mô hình

CREATE TABLE users[ 
    id INT NOT NULL AUTO_INCREMENT, 
    email VARCHAR[100] NOT NULL, 
    password VARCHAR[100] NOT NULL, 
    PRIMARY KEY[id] 
];

CREATE TABLE orders[ 
    id INT NOT NULL AUTO_INCREMENT, 
    user_id INT NOT NULL, 
    description VARCHAR[50] NOT NULL, 
    PRIMARY KEY[id], 
    FOREIGN KEY[user_id] REFERENCES users[id] 
];
1

Có vẻ ổn, nhưng, đợi một chút. Các mục trong đơn đặt hàng này ở đâu? . Giải pháp là cái gọi là bảng tham gia hoặc bảng trung gian. Nói cách khác, chúng ta cần một bảng liên kết để lưu trữ ánh xạ nhiều-nhiều giữa đơn hàng và mặt hàng. Giờ đây, trong thế giới Laravel, có một quy ước được tích hợp sẵn mà chúng ta tuân theo để tiết kiệm thời gian. Nếu tôi tạo một bảng mới bằng cách sử dụng dạng số ít của hai tên bảng, đặt chúng theo thứ tự từ điển và nối chúng bằng dấu gạch dưới, Laravel sẽ tự động nhận dạng đó là bảng nối

Trong trường hợp của chúng tôi, bảng tham gia sẽ được gọi là 

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
32 [từ "item" xuất hiện trước "order" trong từ điển]. Ngoài ra, như đã giải thích trước đây, bảng tham gia này thường chỉ chứa hai cột, các khóa ngoại cho mỗi bảng

Chúng tôi có thể tạo một mô hình + di chuyển ở đây, nhưng mô hình sẽ không bao giờ được sử dụng vì nó là một thứ meta. Vì vậy, chúng ta tạo một migration mới trong Laravel và nói cho nó biết đó là gì

CREATE TABLE users[ 
    id INT NOT NULL AUTO_INCREMENT, 
    email VARCHAR[100] NOT NULL, 
    password VARCHAR[100] NOT NULL, 
    PRIMARY KEY[id] 
];

CREATE TABLE orders[ 
    id INT NOT NULL AUTO_INCREMENT, 
    user_id INT NOT NULL, 
    description VARCHAR[50] NOT NULL, 
    PRIMARY KEY[id], 
    FOREIGN KEY[user_id] REFERENCES users[id] 
];
2

Điều này dẫn đến một lần di chuyển mới, chúng tôi sẽ thay đổi như sau

CREATE TABLE users[ 
    id INT NOT NULL AUTO_INCREMENT, 
    email VARCHAR[100] NOT NULL, 
    password VARCHAR[100] NOT NULL, 
    PRIMARY KEY[id] 
];

CREATE TABLE orders[ 
    id INT NOT NULL AUTO_INCREMENT, 
    user_id INT NOT NULL, 
    description VARCHAR[50] NOT NULL, 
    PRIMARY KEY[id], 
    FOREIGN KEY[user_id] REFERENCES users[id] 
];
3

Làm thế nào để thực sự truy cập các mối quan hệ này thông qua các cuộc gọi phương thức Eloquent là một chủ đề cho phần sau, nhưng lưu ý rằng trước tiên chúng ta cần tạo các khóa ngoại này một cách cẩn thận bằng tay. Không có những thứ này, không có Eloquent và không có "thông minh" trong Laravel. 🙂

Chúng ta đã ở đó chưa? . .

Chúng tôi chỉ có một vài mô hình nữa để lo lắng về. Đầu tiên là bảng hóa đơn và bạn sẽ nhớ rằng chúng tôi đã quyết định biến nó thành mối quan hệ một đối một với các đơn đặt hàng

CREATE TABLE users[ 
    id INT NOT NULL AUTO_INCREMENT, 
    email VARCHAR[100] NOT NULL, 
    password VARCHAR[100] NOT NULL, 
    PRIMARY KEY[id] 
];

CREATE TABLE orders[ 
    id INT NOT NULL AUTO_INCREMENT, 
    user_id INT NOT NULL, 
    description VARCHAR[50] NOT NULL, 
    PRIMARY KEY[id], 
    FOREIGN KEY[user_id] REFERENCES users[id] 
];
4

Trong phần đầu của bài viết này, chúng ta đã thấy rằng một cách để thực thi mối quan hệ một đối một là biến khóa chính trên bảng con thành khóa ngoại. Trong thực tế, hầu như không có ai thực hiện cách tiếp cận quá thận trọng này và mọi người thường thiết kế lược đồ như họ sẽ làm cho mối quan hệ một-nhiều. Quan điểm của tôi là cách tiếp cận ở giữa sẽ tốt hơn; 

CREATE TABLE users[ 
    id INT NOT NULL AUTO_INCREMENT, 
    email VARCHAR[100] NOT NULL, 
    password VARCHAR[100] NOT NULL, 
    PRIMARY KEY[id] 
];

CREATE TABLE orders[ 
    id INT NOT NULL AUTO_INCREMENT, 
    user_id INT NOT NULL, 
    description VARCHAR[50] NOT NULL, 
    PRIMARY KEY[id], 
    FOREIGN KEY[user_id] REFERENCES users[id] 
];
5

Và vâng, lần thứ mười một, tôi biết rằng bảng hóa đơn này còn thiếu rất nhiều thứ;

Được rồi, vậy là chúng ta đã đạt đến điểm mà chúng ta cần tạo lần di chuyển cuối cùng cho hệ thống của mình [tôi hy vọng. ]. Trọng tâm bây giờ là mô hình 

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
33 mà chúng tôi đã quyết định trước đó được liên kết với mô hình 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
31. Nhân tiện, đây là một bài tập dành cho bạn. Thay vào đó, mô hình 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
33 có nên được liên kết với mô hình 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
36 không? 

CREATE TABLE users[ 
    id INT NOT NULL AUTO_INCREMENT, 
    email VARCHAR[100] NOT NULL, 
    password VARCHAR[100] NOT NULL, 
    PRIMARY KEY[id] 
];

CREATE TABLE orders[ 
    id INT NOT NULL AUTO_INCREMENT, 
    user_id INT NOT NULL, 
    description VARCHAR[50] NOT NULL, 
    PRIMARY KEY[id], 
    FOREIGN KEY[user_id] REFERENCES users[id] 
];
6

Và cuộc di cư

CREATE TABLE users[ 
    id INT NOT NULL AUTO_INCREMENT, 
    email VARCHAR[100] NOT NULL, 
    password VARCHAR[100] NOT NULL, 
    PRIMARY KEY[id] 
];

CREATE TABLE orders[ 
    id INT NOT NULL AUTO_INCREMENT, 
    user_id INT NOT NULL, 
    description VARCHAR[50] NOT NULL, 
    PRIMARY KEY[id], 
    FOREIGN KEY[user_id] REFERENCES users[id] 
];
7

Phù. Đó là một số công việc khó khăn. . . hãy chạy di chuyển và xem cách chúng ta đang làm trong mắt cơ sở dữ liệu

CREATE TABLE users[ 
    id INT NOT NULL AUTO_INCREMENT, 
    email VARCHAR[100] NOT NULL, 
    password VARCHAR[100] NOT NULL, 
    PRIMARY KEY[id] 
];

CREATE TABLE orders[ 
    id INT NOT NULL AUTO_INCREMENT, 
    user_id INT NOT NULL, 
    description VARCHAR[50] NOT NULL, 
    PRIMARY KEY[id], 
    FOREIGN KEY[user_id] REFERENCES users[id] 
];
8

Chúc tụng Chúa. 🙏🏻🙏🏻 Có vẻ như chúng ta đã sống sót qua giây phút thử thách

Và với điều đó, chúng tôi đã sẵn sàng để chuyển sang xác định các mối quan hệ mô hình. Để làm được điều đó, chúng ta cần quay lại danh sách đã tạo trước đó, phác thảo loại mối quan hệ trực tiếp giữa các mô hình [bảng]

Để bắt đầu, chúng tôi đã xác định rằng có mối quan hệ một-nhiều giữa người dùng và đơn đặt hàng. Chúng tôi có thể xác nhận điều này bằng cách truy cập tệp di chuyển của đơn đặt hàng và thấy sự hiện diện của trường 

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
92 ở đó. Trường này là thứ tạo ra mối quan hệ, bởi vì bất kỳ mối quan hệ nào chúng tôi quan tâm đến việc thiết lập đều cần được cơ sở dữ liệu tôn trọng trước tiên;

Nói cách khác, mối quan hệ đã có sẵn. Chúng ta chỉ cần yêu cầu Eloquent cung cấp nó trong thời gian chạy. Hãy bắt đầu với mô hình 

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
31, nơi chúng tôi tuyên bố rằng nó thuộc về mô hình 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
95

CREATE TABLE users[ 
    id INT NOT NULL AUTO_INCREMENT, 
    email VARCHAR[100] NOT NULL, 
    password VARCHAR[100] NOT NULL, 
    PRIMARY KEY[id] 
];

CREATE TABLE orders[ 
    id INT NOT NULL AUTO_INCREMENT, 
    user_id INT NOT NULL, 
    description VARCHAR[50] NOT NULL, 
    PRIMARY KEY[id], 
    FOREIGN KEY[user_id] REFERENCES users[id] 
];
9

Cú pháp phải quen thuộc với bạn; . Hãy nghĩ lại một chút - nếu không có cơ sở dữ liệu và không có khóa ngoại, một câu lệnh như 

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
61 sẽ là vô nghĩa. Chỉ vì có một khóa ngoại trên bảng 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
9 mà Laravel có thể sử dụng 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
92 đó để tra cứu người dùng có cùng một 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
5 và trả lại. Tự nó, không có sự hợp tác của cơ sở dữ liệu, Laravel không thể tạo ra các mối quan hệ ngoài luồng

Bây giờ, thật tuyệt nếu có thể viết 

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
65 để truy cập đơn đặt hàng của người dùng. Điều này có nghĩa là chúng ta cần chuyển sang mô hình 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
95 và viết ra một hàm cho phần “nhiều” của mối quan hệ một-nhiều này

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
30

Có, tôi đã sửa đổi rất nhiều mô hình mặc định của 

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
95 vì chúng tôi không cần tất cả các chức năng khác cho hướng dẫn này. Dù sao, lớp 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
95 hiện có một phương thức gọi là 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
69, cho biết một người dùng có thể được liên kết với nhiều đơn đặt hàng. Trong thế giới ORM, chúng tôi nói rằng mối quan hệ 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
69 ở đây là nghịch đảo của mối quan hệ 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
60 mà chúng tôi đã có trên mô hình 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
31

Nhưng, đợi một chút. Làm thế nào là mối quan hệ này làm việc?

Trên thực tế, đã có một kết nối hiện có và hóa ra chỉ cần kết nối đó là đủ — tham chiếu khóa ngoại được lưu trữ trong bảng 

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
9. Đây là, khi chúng ta nói điều gì đó như 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
65, Laravel nhấn hàm 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
69 và biết bằng cách nhìn vào nó rằng có một khóa ngoại trên bảng 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
9. Sau đó, nó thực hiện một 
class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
79 và trả về kết quả truy vấn dưới dạng một tập hợp. Tất nhiên, mục đích của việc có một ORM là quên SQL đi, nhưng chúng ta không nên quên hoàn toàn rằng cơ sở bên dưới là RDBMS chạy các truy vấn SQL

Tiếp theo, hãy lướt qua các mô hình đơn đặt hàng và hóa đơn, nơi chúng ta có mối quan hệ một đối một

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
31

Và mẫu hóa đơn

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
32

Lưu ý rằng ở cấp độ cơ sở dữ liệu, cũng như gần như ở cấp độ Eloquent, đó là mối quan hệ một-nhiều điển hình;

Bây giờ chúng ta đến với một kiểu quan hệ khác - quan hệ nhiều-nhiều giữa đơn đặt hàng và mặt hàng. Nhớ lại rằng chúng ta đã tạo một bảng trung gian có tên là 

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
32 lưu trữ ánh xạ giữa các khóa chính. Nếu điều này đã được thực hiện chính xác, việc xác định mối quan hệ và làm việc với nó là chuyện nhỏ. Theo các tài liệu của Laravel, để xác định mối quan hệ nhiều-nhiều, các phương thức của bạn phải trả về một phiên bản 
CREATE TABLE users[ 
    id INT NOT NULL AUTO_INCREMENT, 
    email VARCHAR[100] NOT NULL, 
    password VARCHAR[100] NOT NULL, 
    PRIMARY KEY[id] 
];

CREATE TABLE orders[ 
    id INT NOT NULL AUTO_INCREMENT, 
    user_id INT NOT NULL, 
    description VARCHAR[50] NOT NULL, 
    PRIMARY KEY[id], 
    FOREIGN KEY[user_id] REFERENCES users[id] 
];
01

Vì vậy, trong mô hình 

CREATE TABLE users[ 
    id INT NOT NULL AUTO_INCREMENT, 
    email VARCHAR[100] NOT NULL, 
    password VARCHAR[100] NOT NULL, 
    PRIMARY KEY[id] 
];

CREATE TABLE orders[ 
    id INT NOT NULL AUTO_INCREMENT, 
    user_id INT NOT NULL, 
    description VARCHAR[50] NOT NULL, 
    PRIMARY KEY[id], 
    FOREIGN KEY[user_id] REFERENCES users[id] 
];
02

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
33

Đáng ngạc nhiên, mối quan hệ nghịch đảo gần như giống hệt nhau

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
34

Và đó là nó. Miễn là chúng ta tuân thủ đúng các quy ước đặt tên, Laravel có thể suy ra các ánh xạ cũng như vị trí của chúng

Vì tất cả ba loại quan hệ cơ bản đã được đề cập [một-đối-một, một-nhiều, nhiều-nhiều], tôi sẽ ngừng viết các phương thức cho các mô hình khác, vì chúng sẽ theo sau. . Thay vào đó, hãy tạo các nhà máy cho các mô hình này, tạo một số dữ liệu giả và xem các mối quan hệ này hoạt động

làm sao chúng ta làm việc đó bây giờ? . Sau đó, khi chúng tôi chạy di chuyển, chúng tôi cũng sẽ chạy seeder. Vì vậy, đây là tệp 

CREATE TABLE users[ 
    id INT NOT NULL AUTO_INCREMENT, 
    email VARCHAR[100] NOT NULL, 
    password VARCHAR[100] NOT NULL, 
    PRIMARY KEY[id] 
];

CREATE TABLE orders[ 
    id INT NOT NULL AUTO_INCREMENT, 
    user_id INT NOT NULL, 
    description VARCHAR[50] NOT NULL, 
    PRIMARY KEY[id], 
    FOREIGN KEY[user_id] REFERENCES users[id] 
];
03 của tôi trông như thế nào

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
35

Và bây giờ chúng tôi thiết lập lại cơ sở dữ liệu và khởi tạo nó

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
36

Tất cả, phải. Bây giờ là phần cuối cùng của bài viết này, nơi chúng tôi chỉ cần truy cập các mối quan hệ này và xác nhận tất cả những gì chúng tôi đã học được cho đến nay. Bạn sẽ rất vui khi biết [tôi hy vọng] rằng đây sẽ là một chuyên mục nhẹ nhàng và thú vị

Và bây giờ, hãy kích hoạt thành phần thú vị nhất của Laravel — bảng điều khiển tương tác Tinker

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
37

Truy cập các mối quan hệ mô hình một đối một trong Laravel Eloquent

Được rồi, trước tiên, hãy truy cập vào mối quan hệ một đối một mà chúng ta có trong các mô hình đặt hàng và hóa đơn

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
38

Nhận thấy một cái gì đó? . Vì vậy, kết quả là Laravel có thể đã trả về một tập hợp các đối tượng [hoặc chỉ một đối tượng] và điều đó sẽ chính xác về mặt kỹ thuật. NHƯNG. . . chúng tôi đã nói với Laravel rằng đó là mối quan hệ một đối một, vì vậy, kết quả là một phiên bản Eloquent duy nhất. Lưu ý cách điều tương tự xảy ra khi truy cập vào mối quan hệ nghịch đảo

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
39

Truy cập các mối quan hệ mô hình một-nhiều trong Laravel Eloquent

Chúng tôi có mối quan hệ một-nhiều giữa người dùng và đơn đặt hàng. Hãy cùng “mò” nó ngay và xem kết quả nhé

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
0

Đúng như mong đợi, việc truy cập đơn đặt hàng của người dùng dẫn đến một tập hợp các bản ghi, trong khi ngược lại chỉ tạo ra một đối tượng 

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
95 duy nhất. Nói cách khác, một-nhiều

Truy cập mô hình quan hệ nhiều-nhiều trong Laravel Eloquent

Bây giờ, hãy khám phá mối quan hệ nhiều-nhiều. Chúng tôi có một mối quan hệ như vậy giữa các mặt hàng và đơn đặt hàng

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
1

Đầu ra này có thể hơi chóng mặt khi đọc qua nhưng hãy lưu ý rằng item1 là một phần của các item của order1 và ngược lại, đó là cách chúng tôi thiết lập mọi thứ. Chúng ta cũng hãy xem qua bảng trung gian lưu trữ các ánh xạ

class CreateUsersTable extends Migration
{
    public function up[]
    {
        Schema::create['users', function [Blueprint $table] {
            $table->id[];
            $table->string['name'];
        }];
    }
}
2

Phần kết luận

Vâng, đây là nó, thực sự. Đó là một bài viết thực sự dài, nhưng tôi hy vọng nó hữu ích. Đó có phải là tất cả những gì bạn cần biết về Laravel models không?

Thật đáng buồn không. Hố thỏ thực sự, rất sâu và có nhiều khái niệm thách thức hơn như Mối quan hệ đa hình và điều chỉnh hiệu suất, v.v., mà bạn sẽ gặp phải khi phát triển với tư cách là nhà phát triển Laravel. Hiện tại, những gì bài viết này đề cập là đủ cho 70% nhà phát triển trong 70% thời gian, đại khái là. Sẽ rất lâu nữa bạn mới cảm thấy cần phải nâng cấp kiến ​​thức của mình

Với thông báo trước đó, tôi muốn bạn loại bỏ thông tin chi tiết quan trọng nhất này. không có gì là ma thuật đen tối hoặc ngoài tầm với trong lập trình. Chỉ là chúng ta không hiểu nền tảng và cách mọi thứ được xây dựng, điều đó khiến chúng ta loay hoay và cảm thấy thất vọng.

Cho nên. . . ?

Đầu tư vào bản thân. Các khóa học, sách, bài báo, các cộng đồng lập trình khác [Python là đề xuất số 1 của tôi] — sử dụng bất kỳ tài nguyên nào bạn có thể tìm thấy và sử dụng chúng thường xuyên nếu chậm. Chẳng bao lâu nữa, số lượng các trường hợp mà bạn có khả năng làm hỏng toàn bộ sự việc sẽ giảm đi đáng kể

eloquent trong Laravel là gì?

Eloquent là một trình ánh xạ quan hệ đối tượng [ORM] được bao gồm theo mặc định trong khung Laravel . ORM là phần mềm hỗ trợ xử lý các bản ghi cơ sở dữ liệu bằng cách biểu diễn dữ liệu dưới dạng các đối tượng, hoạt động như một lớp trừu tượng trên cùng của công cụ cơ sở dữ liệu được sử dụng để lưu trữ dữ liệu của ứng dụng.

Việc sử dụng mối quan hệ trong Laravel là gì?

Mối quan hệ một đối một cung cấp mối quan hệ một đối một giữa các cột của các bảng khác nhau . Ví dụ: mỗi người dùng được liên kết với một bài đăng hoặc có thể nhiều bài đăng, nhưng trong mối quan hệ này, chúng tôi sẽ truy xuất một bài đăng của người dùng.

Tôi có thể sử dụng ORM hùng hồn mà không cần Laravel không?

Sử dụng ORM . Tất cả những gì bạn phải làm là khai báo mô hình của mình như bạn vẫn thường làm. Sau đó, bạn cần gọi nó và sử dụng nó như bạn đã quen. Using the Eloquent ORM in a non-Laravel application is not a big change. All you have to do is to declare your model as you are used to doing. Then, you need to call it and use it as you are used to.

Tải háo hức và tải lười biếng trong Laravel là gì?

Sự khác biệt chính giữa tải háo hức và lười biếng là tải háo hức lấy tất cả dữ liệu có bản ghi mối quan hệ trong một truy vấn duy nhất và tải chậm yêu cầu N+1 truy vấn để lấy dữ liệu quan hệ và mô hình chính< . Háo hức tải chạy một truy vấn trong khi lười tải chạy N+1 truy vấn. . Eager loading run single query whereas lazy loading run N+1 queries.

Bài Viết Liên Quan

Làm cách nào tôi có thể lấy một phần của chuỗi trong JavaScript?
Tệp vượt qua Python dưới dạng biến
Ai là người trong dự thảo NBA 2023?
Vỏ tương tác trong Python
Tải dữ liệu từ Excel sang SQL Server bằng SSIS Script Task
Cài đặt python 3 ubuntu mới nhất
Điều gì sẽ là đầu ra của mã PHP sau đây PHP x;
Who is touring England in 2023?
Giải thích bất kỳ 5 thẻ html nào với các ví dụ
Ví dụ xuất excel
Danh sách quốc gia HTML
Tại sao trình đơn thả xuống không hoạt động trong bootstrap 5?
Nhật Bản thời tiết Tháng 7 2023
1m nước bằng bao nhiêu pa
Nhận cùng một giá trị khóa từ mảng php
SQL trích xuất văn bản từ HTML
Làm cách nào để viết mã cho nút chỉnh sửa trong PHP?
Error_reporting 0 là gì);
Tại sao vòng lặp được sử dụng trong python?
SQL COUNT nhóm THEO nhiều cột

Toplist mới

#1
Top 9 review kem chống nắng cho bà bầu 2023
7 tháng trước
#2
Top 5 tiếng anh lớp 2 unit 7 trang 46 2023
7 tháng trước
#3
Top 10 tải: mẫu the nhân viên trên excel 2023
7 tháng trước
#4
Top 7 tuyển dụng nhân viên chốt đơn tại nhà 2023
7 tháng trước
#5
Top 7 mẫu nhà 2 tầng chữ l 100m2 mái bằng 2023
7 tháng trước
#6
Top 4 truyện ngắn về quê hương lớp 2 2023
7 tháng trước
#7
Top 6 sơ đồ bộ máy nhà nước thời hồ 2023
7 tháng trước
#8
Top 8 trước việc nhật đảo chính pháp, đảng ta có chủ trương gì mới 2023
7 tháng trước
#9
Top 7 dân số đông đã đem đến cho nước ta 2023
7 tháng trước

Bài mới nhất

Castlevania lords of shadow 2 việt hóa fshare năm 2024
Đặt bàn thờ ông táo như thế nào năm 2024
Cach fix lỗi ko vào trân dc lol năm 2024
Bài tập tiếng anh lưu hoằng trí lớp 8 violet năm 2024
Bị lỗi không thành hoa trong word 2023 năm 2024
Nên dùng biện pháp tránh thai nào sau sinh năm 2024
Lỗi không đang nhập được đồng bộ hóa coccoc năm 2024
Chữa thoái hóa xương khớp của đỗ đưcs ngocj năm 2024
Tìm lỗi sai eggs are taken to the mảket fridays năm 2024
Bột diệp lục unicity được sản xuất như thế nào năm 2024

Chủ Đề

Toplist programming Địa Điểm Hay Hỏi Đáp Là gì Mẹo Hay Nghĩa của từ Học Tốt Công Nghệ mẹo hay Khỏe Đẹp bao nhiêu Top List Bao nhiêu Sản phẩm tốt Bài Tập Xây Đựng Ngôn ngữ đánh giá Tiếng anh Bài tập So Sánh Ở đâu So sánh Hướng dẫn Dịch bao nhieu Tại sao Đại học hướng dẫn Thế nào Máy tính Vì sao Bao lâu Khoa Học Hà Nội