Tôi có nên tạo một con sên khi đang bay hoặc lưu trữ trong DB không?

Question

Sên là một phần của URL mô tả hoặc tiêu đề một trang và thường là từ khóa phong phú cho trang đó cải thiện SEO. ví dụ. Trong URL này PHP/JS - Create thumbnails on the fly or store as files phần cuối cùng "php-js-create-thumbnails-on-the-fly-hoặc-store-as-files" là sên.

Hiện tại tôi đang lưu trữ sên cho mỗi trang có bản ghi của trang trong DB. Sên được tạo từ trường Tiêu đề khi trang được tạo và lưu trữ với trang. Tuy nhiên, tôi đang xem xét việc tạo ra các slug trên bay trong trường hợp tôi muốn thay đổi nó. Tôi đang cố gắng tìm ra cái nào tốt hơn và những gì người khác đã làm.

Cho đến nay tôi đã đi lên với những điểm pro cho mỗi người:

cửa hàng sên: - "Nhanh hơn" xử lý không cần phải tạo ra nó mỗi lần (được tạo ra một lần)

Tạo liên tục: - Linh hoạt (có thể điều chỉnh thuật toán slug và không cần phải regen cho toàn bộ bảng). - Sử dụng ít không gian hơn trong DB - Ít dữ liệu được chuyển từ DB sang Ứng dụng

Tôi còn nhớ điều gì khác và bạn sẽ làm như thế nào?

EDIT:

Tôi muốn làm rõ những gì trông giống như một sự hiểu lầm trong câu trả lời. Slug không ảnh hưởng đến việc hạ cánh trên đúng trang. Để hiểu điều này chỉ cần cắt hoặc xé bất kỳ phần nào của sên trên trang web này. ví dụ .:

PHP/JS - Create thumbnails on the fly or store as files

PHP/JS - Create thumbnails on the fly or store as files

PHP/JS - Create thumbnails on the fly or store as files

tất cả sẽ đưa bạn đến cùng một trang. Sên không bao giờ được lập chỉ mục.

Bạn sẽ không cần lưu các sên cũ. Nếu bạn đã hạ cánh trên một trang có một "con sên cũ" thì bạn có thể phát hiện ra điều đó và chỉ thực hiện chuyển hướng 301 đến trang "slugged" chính xác. Trong ví dụ trên, nếu Stack Overflow triển khai nó, thì khi bạn truy cập vào bất kỳ liên kết nào có sên bị cắt ngắn ở trên, nó sẽ so sánh slug trong url với địa chỉ được tạo bởi thuật toán sên hiện tại và nếu khác thì nó sẽ thực hiện 301 chuyển hướng đến cùng một trang nhưng với slug mới.

Hãy nhớ rằng tất cả các liên kết được tạo nội bộ sẽ ngay lập tức sử dụng thuật toán mới và chỉ các liên kết từ bên ngoài trỏ vào sẽ sử dụng sên cũ.

Answer 1

Bạn có thể cần phải cân nhắc một điều khác, nếu bạn muốn người dùng/chính mình có thể định nghĩa các sên riêng của họ. Có lẽ thuật toán không phải lúc nào cũng đủ.

Nếu như vậy bạn ít nhiều cũng cần lưu trữ nó trong cơ sở dữ liệu.

Nếu không, tôi không nghĩ rằng nó quan trọng, bạn có thể tạo chúng một cách nhanh chóng, nhưng nếu bạn không chắc liệu bạn có muốn thay đổi chúng hay không để chúng ở trong cơ sở dữ liệu. Trong đôi mắt của tôi không có vấn đề hiệu suất thực sự với một trong hai phương pháp (trừ khi thế hệ on-the-fly là rất chậm hoặc một cái gì đó như thế).

Chọn loại linh hoạt nhất.

Answer 2

Sẽ không thay đổi các sên cho các trang hiện có là một ý tưởng thực sự tồi? Nó sẽ phá vỡ tất cả các liên kết của bạn cho một sự khởi đầu.

Chỉnh sửa, theo dõi rõ ràng của Guy trong câu hỏi: Bạn vẫn cần phải xem xét các lỗi cũ. Ví dụ: nếu bạn thay đổi thuật toán sên của mình, Google có thể bắt đầu thấy nhiều phiên bản của từng trang và bạn có thể bị phạt nội dung trùng lặp hoặc kết thúc tốt nhất việc chia sẻ PR và SERP giữa nhiều phiên bản của cùng một trang. Để tránh điều đó, bạn cần một phiên bản chuẩn của trang mà bất kỳ sên không chuẩn tắc nào được chuyển hướng đến - và do đó bạn sẽ cần sên chuẩn trong cơ sở dữ liệu.

Answer 3

Đối với thế hệ slug Tôi không nghĩ rằng thời gian tạo nên là một vấn đề, trừ khi thuật toán slug của bạn cực kỳ phức tạp! Tương tự, không gian lưu trữ sẽ không là vấn đề.

Tôi sẽ lưu trữ con sên trong cơ sở dữ liệu vì lý do đơn giản là sên thường tạo thành một phần của một liên kết cố định và một khi một liên kết nằm trong tự nhiên, nó sẽ được coi là không thay đổi. Có khả năng thay đổi một con sên cho dữ liệu được xuất bản có vẻ như là một ý tưởng tồi.

Answer 4

Cách tốt nhất để xử lý các slugs là chỉ lưu trữ phần nói của slug trong cơ sở dữ liệu và giữ phần định tuyến với mã định danh duy nhất để tạo năng động. Nếu không, nếu bạn lưu trữ toàn bộ url hoặc uri trong cơ sở dữ liệu, nó có thể trở thành một nhiệm vụ lớn để viết lại tất cả các sên trong cơ sở dữ liệu trước nếu bạn đổi ý về cách gọi chúng.

Chúng ta hãy hỏi này SO sên làm ví dụ:

/thắc mắc/807.195/nên-i-tạo-một-sên-on-the-fly-hoặc-store-in-db

nó :

/route/unique-ID/the-speaking-part-thats-not-so-important 

phần động là rõ ràng:

/route/unique-ID/ 

Và người tôi sẽ lưu trữ trong cơ sở dữ liệu là s phần đỉnh:

the-speaking-part-thats-not-so-important 

Điều này cho phép bạn luôn thay đổi ý định về tên của tuyến đường và không cần phải nhìn vào bên trong cơ sở dữ liệu trước và bạn không bị buộc phải thực hiện thay đổi db. Id duy nhất luôn là ID duy nhất của dữ liệu cơ sở dữ liệu để bạn có thể xác định nó chính xác và bạn biết nguyên tắc của mình là gì.

Và đừng quên đặt thẻ chuẩn. Nếu bạn nhìn vào bên trong mã trang này, hãy xem:

<link rel="canonical" href="http://stackoverflow.com/questions/807195/should-i-create-a-slug-on-the-fly-or-store-in-db" /> 

Điều này cho phép công cụ tìm kiếm xác định liên kết trang chính xác và bỏ qua những người khác trong trường hợp bạn có nội dung trùng lặp.