2010-01-30 22 views
7

Đây là một câu hỏi ngớ ngẩn, nhưng đó là câu hỏi mà tôi chưa bao giờ được trả lời thẳng.

Câu hỏi thực hành tốt nhất cho MySQL: thứ tự theo id hoặc ngày?

Giả sử tôi có một bảng DB với các lĩnh vực và các giá trị sau:

| id | date_added   | balance | 
+------------------------------------+ 
| 1 | 2009-12-01 19:43:22 | 1237.50 | 
| 2 | 2010-01-12 03:19:54 | 473.00 | 
| 3 | 2010-01-12 03:19:54 | 2131.20 | 
| 4 | 2010-01-20 11:27:31 | 3238.10 | 
| 5 | 2010-01-25 22:52:07 | 569.40 | 
+------------------------------------+  


này là dành cho 'chiếm' một rất cơ bản hệ thống phụ. Tôi muốn có số dư gần đây nhất. Trường id được đặt thành auto_increment. Thông thường, tôi sẽ sử dụng:

SELECT balance FROM my_table ORDER BY date_added DESC LIMIT 1;

Nhưng tôi cần phải thực hiện hoàn toàn chắc chắn rằng giá trị trả về là gần đây nhất ... (xem id # 2 & 3 nêu trên)

1) tôi sẽ tốt hơn bằng cách sử dụng:

SELECT balance FROM my_table ORDER BY id DESC LIMIT 1;

2) Hoặc đây sẽ là một giải pháp tốt hơn ?:

SELECT balance FROM my_table ORDER BY date_added,id DESC LIMIT 1;


AFAIK, auto_increment hoạt động khá tốt, nhưng nó đủ tin cậy để sắp xếp một cái gì đó rất quan trọng này bởi? Đó là lý do tại sao tôi đang suy nghĩ phân loại theo cả hai lĩnh vực là một ý tưởng tốt hơn, nhưng tôi đã nhìn thấy một số hành vi thực sự kỳ quặc trong MySQL khi tôi đã làm điều đó trong quá khứ. Hoặc nếu có một giải pháp tốt hơn, tôi sẽ đánh giá cao ý kiến ​​của bạn.


Cảm ơn bạn trước!

Brian

Trả lời

7

Nếu có một cơ hội bạn sẽ nhận được hai thêm với cùng ngày, có thể bạn sẽ cần:

SELECT balance FROM my_table ORDER BY date_added DESC,id DESC LIMIT 1; 

(lưu ý 'tự giảm dần' khoản trên cả hai lĩnh vực).

Tuy nhiên, bạn sẽ cần phải đưa vào tài khoản những gì bạn muốn xảy ra khi ai đó thêm một mục điều chỉnh của 2 các thứ tháng Hai được đưa ra ngày 31 st tháng giêng đến đảm bảo tháng tháng hoàn tất . Nó sẽ có một ID lớn hơn ID được thực hiện trên số 01 st của tháng Hai.

Nói chung, các hệ thống kế toán chỉ hoạt động vào ngày. Có lẽ nếu bạn có thể cho chúng tôi biết lý do tại sao đơn đặt hàng là quan trọng, chúng tôi có thể đưa ra các đề xuất khác.


Đáp lại bình luận của bạn:

Tôi rất thích nghe bất kỳ ý tưởng khác hoặc tư vấn bạn có thể có, ngay cả khi họ đang off-topic kể từ khi tôi có zero kiến ​​thức về kế toán-type mô hình cơ sở dữ liệu.

Tôi sẽ cung cấp một vài lời khuyên - đây là tất cả những gì tôi có thể nghĩ ngay lập tức, tôi thường giải thích nhiều hơn "lời khuyên" với ít khuyến khích hơn :-) Hai đầu tiên, liên quan đến cơ sở dữ liệu nhiều hơn - có liên quan, là:

Đầu tiên, hãy làm mọi thứ ở dạng bình thường thứ ba và chỉ hoàn nguyên nếu và khi bạn gặp sự cố về hiệu suất. Điều này sẽ giúp bạn tiết kiệm rất nhiều angst với dữ liệu trùng lặp mà có thể nhận được ra khỏi bước. Ngay cả khi bạn hoàn nguyên, hãy sử dụng trình kích hoạt và các khả năng DBMS khác để đảm bảo rằng dữ liệu không thoát khỏi bước.

Ví dụ, nếu bạn muốn tăng tốc tìm kiếm của mình trên cột last_name, bạn có thể tạo cột upper_last_name (được lập chỉ mục) rồi sử dụng để xác định vị trí các bản ghi khớp với cụm từ tìm kiếm đã xếp chồng trên của bạn. Điều này hầu như luôn luôn nhanh hơn chức năng mỗi hàng upper(last_name). Bạn có thể sử dụng trình kích hoạt chèn/cập nhật để đảm bảo upper_last_name luôn được đặt chính xác và điều này chỉ xảy ra khi tên thay đổi, không phải mỗi khi bạn tìm kiếm. Thứ hai, không sao chép dữ liệu ngay cả trên các bảng (như lược đồ hiện tại của bạn) trừ khi bạn có thể sử dụng những thủ thuật loại kích hoạt tương tự để đảm bảo dữ liệu sẽ không thoát khỏi bước. Khách hàng của bạn sẽ làm gì khi bạn gửi cho họ một hóa đơn mà số dư cuối cùng không khớp với số dư ban đầu cộng với số lần mua hàng? Điều đó sẽ không làm cho công ty của bạn trông rất chuyên nghiệp :-)

Thứ ba (và điều này liên quan đến kế toán nhiều hơn), bạn thường không cần phải lo lắng về số lượng giao dịch khi tính toán số dư khi đang bay. Đó là bởi vì các hệ thống kế toán thường có chức năng roll-over vào cuối năm mà reset số dư mở.

Vì vậy, bạn thường không bao giờ phải xử lý nhiều hơn một năm giá trị dữ liệu cùng một lúc, trừ khi bạn là chính phủ Hoa Kỳ hoặc Microsoft, không phải là công việc đó.

+0

Cảm ơn Pax! Thực sự là một trường tôi đã rời khỏi bảng và đó là user_id. Chúng tôi có một hệ thống 'tín dụng' mà người dùng của chúng tôi có thể sử dụng để mua hàng hóa hoặc dịch vụ và chúng tôi đang giữ tổng số dư của họ trong bảng này. Để có được 'số dư hiện tại', tôi muốn chọn số dư gần đây nhất từ ​​bảng cụ thể này. Bảng trên được cập nhật bất cứ lúc nào một giao dịch được thực hiện. (tất cả các giao dịch được lưu trữ trong một bảng riêng). Tôi hy vọng điều đó có ý nghĩa, lol. – DondeEstaMiCulo

+0

Hmm, đó không phải là cách tôi làm nhưng với mỗi cái riêng của họ :-) Tôi sẽ tính toán số dư dựa trên tất cả các mục giao dịch của họ (tùy chọn của tôi vì có * không * cơ hội dữ liệu thoát khỏi bước giữa hai bảng), hoặc chỉ duy trì * một * bản ghi cho mỗi người dùng với số dư hiện tại và cập nhật nó. Trong thực tế, tôi không thể mang lại cho mình để đề nghị lựa chọn thứ hai ở tất cả bây giờ mà tôi nghĩ về nó. Bạn cần phải cẩn thận với giải pháp hiện tại của mình vì bạn đang giữ dữ liệu ở hai nơi khác nhau có thể không đồng ý với nhau. – paxdiablo

+0

Vâng, chúng tôi muốn giữ lại lịch sử cân bằng nếu không có gì khác ngoài mục đích báo cáo nội bộ. Tôi đã thực sự nghĩ về ý tưởng của bạn về tính toán tất cả các giao dịch là tốt, nhưng figured cách trên có thể được dễ dàng hơn. Có lẽ tôi sẽ nghĩ lại ý tưởng đó. ;) Tôi rất thích nghe bất kỳ ý tưởng hoặc lời khuyên nào khác mà bạn có thể có, ngay cả khi họ không có chủ đề vì tôi không có kiến ​​thức về các mô hình cơ sở dữ liệu kiểu kế toán. ;) Cảm ơn một lần nữa! – DondeEstaMiCulo

2

Cá nhân tôi không bao giờ tin tưởng vào tự động theo cách đó. Tôi sắp xếp theo ngày.

Tôi chắc chắn rằng ID được đảm bảo là duy nhất, nhưng không nhất thiết phải tuần tự và tăng lên.

+3

Tự động sắp xếp của MySQL sẽ không bao giờ chèn số thấp hơn số cuối cùng mà nó chèn vào. Đó là một số an toàn để dựa vào nếu bạn muốn có giao dịch mới nhất trong cơ sở dữ liệu. –

3

Có thể nhanh hơn theo id nhưng an toàn hơn theo giờ; sử dụng sau này nếu có vấn đề hiệu suất thêm một chỉ mục.

Các vấn đề liên quan