Phạm Anh Tuấn

@temp là cách bạn đang tính dùng declare trong mysql. Nhưng theo mình thì nó hoạt động không tốt như trong thằng mssql . Điều nữa bạn đang dùng case when then vô tội vạ VD như này nhé:

CONCAT(
    "",
    GROUP_CONCAT(
        CASE 
          WHEN `repitte_beauty`.`reserve`.`status` = 1 AND `repitte_beauty`.`reserve`.`date` <= CURDATE() THEN '1' 
          WHEN `repitte_beauty`.`reserve`.`status` = 1 AND `repitte_beauty`.`reserve`.`date` > CURDATE() THEN '2' 
          WHEN `repitte_beauty`.`reserve`.`status` <> 1 THEN '0'
        END SEPARATOR ','
    ),
    ","
)

Kết quả theo mình thấy thì nod đang là concat("",group_concat('1').",") đấy lá nếu may mắn nó chạy được nhé cái này chạy được thì kết quả là 1,, Theo mình biết group_concat để nối giá trị của nhiều field trong table mà bạn query lại với nhau. Nếu thế thì giờ nó đang không được đúng lắm.

Còn case trên case when @temp vậy so sánh của nó là gì ?. Có vẻ bạn đang suy nghĩ phức tạp hóa quá. Hãy thử cách này xem

(
  CASE
    WHEN `repitte_beauty`.`reserve`.`status` = 1 THEN 'visited, booking'
    WHEN `repitte_beauty`.`reserve`.`status` = 1 AND `repitte_beauty`.`reserve`.`date` <= CURDATE() THEN 'visited' 
    WHEN `repitte_beauty`.`reserve`.`status` = 1 AND `repitte_beauty`.`reserve`.`date` > CURDATE() THEN 'booking' 
    ELSE 'not visited'
  END
) AS booking_status

Lỗi đang được khắc phục ngay mai các bạn quay lại cầy rank tiếp nhé . Mà nếu tự tin thì cứ submit thẳng là ok.

Bạn nên phân biệt rõ ràng như sau để dễ thao tác.

• Bảng Users hay Accounts,.. là một loại bảng lưu dữ thông tìn người dùng và những thông tin này thường ngoài là thông tin cá nhân thì nó còn là những thông tin của họ liên quan trực tiếp đến nghiệp vụ trang web. Đây là những thông tin bắt buộc 1 user phải có và chỉ có một VD: Web quản lý nhân viên: Ngoài thông tin cá nhân thì bạn cần thêm các thông tin như mã nhân viên, mã số thuế,...

• Còn những thông tin phụ liên quan đến user bạn nên tách ra để cho dễ thực hiện với những yêu cầu tiếp theo của dự án hoặc là user đó sở hữu nhiều thông tin cùng loại.

• Trong trường hợp trên của bạn mình nghĩ bạn nên thiết kế như này

table_user

table_experience

table_degree (bao gồm cả bằng ĐH hay chứng chỉ)

• Còn như trong ảnh là thông tin mô tả nhanh để người bên phía môi giới việc làm loc ra và đưa cho người tuyển dụng. Nó đơn thuần chỉ là 1 bảng dữ liệu chung hoặc tệ hơn thì là 1 google sheet. Và nếu muốn làm tổng quan thì bạn nên tách nhỏ form đó ra thành những đối tượng riêng rẽ và join lại với nhau qua 1 bảng trung gian là đc.

Bạn có thể làm theo cách này nó là cách chung. Nhưng muốn tối ưu nhất để tối ưu nhất thì bạn nên thêm những trường như: Hasttag, size, description về mầu sắc, hình thái,.. Ngoài ra còn có nhiều cách để tối ưu để khi người dùng tìm kiếm bạn có thể đưa ra cho người dùng những sản phẩn gần chính xác theo ý họ nhất

1. Khi bạn làm việc ở môi trường develop vs test thì nó mới hiện lỗi thôi bạn. Còn trên product thì rails có care việc này rồi và nó sẽ dẫn đến đường dẫn đến những file 404 hay 500 nằm ở thư mục public. Và bạn hoàn toàn có thể config lại nó hoặc tạo riêng. Mình thường làm theo cách này . link

2. Việc lưu ảnh trong dự án là điều tất nhiên. Nhưng nó thưởng chỉ lưu những ảnh banner hay logo vì nó là những ảnh public và thường ít khi thay đổi. Còn những loại ảnh khác thì mình thường lưu trên các cloud như aws, Azure,... hay nếu muốn free thì cloudinary.

• Còn gem minimagick bạn đề cập đến theo mình làm thì nó không làm giảm kích thước ảnh mà nó tạo ra ảnh mới với kích thước bạn yêu cầu và bạn lựa chọn càng nhiều loại kích thước thì bạn lại càng có nhiều ảnh thumb. Đây là thủ thuật crop đó.

Đó là ý kiến cá nhân của mình từ những thứ mình đã làm. Nếu có sai sót mong mọi người góp ý thêm .

Một sai lầm khi nói rằng nchar hay n[var]char lưu đc unicode còn char hay [var]char thì là ununicode. Ngôn ngữ mà chúng ta nhìn thấy nó có sự phức tạp riêng còn nếu đưa lên máy tính thì nó chỉ là dạng byte mà thôi.

Còn về việc vì sao chúng ta vẫn có thể lưu các ký tự dạng unicode vào char thì theo mình là như này.

char nó sẽ biểu diễn ký tự dưới dạng 1 byte và chuẩn thì chính là bảng mã ASCII. nchar thì ngược lại bạn cần phải có tối thiểu là 2 byte (Tối thiểu bởi vì trước 2012 chúng ta dùng Utf-8 nhưng từ sau 2012 một số hệ quản trị đã nâng cấp lên Utf-16)

Vậy nếu 1 ký tự unicode có thể bểu diễn dưới dạng 1 byte thì hiển nhiên nó có thể lưu vào field có type là char rồi. Còn lại nếu không biểu thị đc thì thường từ đó sẽ được biểu diễn bằng các ký tự đặc biệt, thông thường là dấu ?.

Đây là ý kiến cá nhân của mình theo 1 chiều nếu có gì không được mong các bạn góp ý. Mình sẽ cố gắng tìm hiểu và sửa chữa.

Mình đang không hiểu câu hỏi của bạn là:

1, Sử dụng loại hình CSDL (NoSql, RDBMs,..) nào cho vấn đề sử dụng những dữ liệu lớn lên đến > 1 tỷ bản ghi trong 1 bảng

hay là

Những giải pháp, biện pháp nào tổ chức dữ liệu ra sao khi làm việc với những db khủng.

Câu trả lời của mình về vấn đề này là như sau (bạn tùy ý tham khảo nhé ):

1, Việc bạn sử dụng dữ liệu kiểu NoSql hay RDBMs nó có ý nghĩa quyết định rất lớn đến hiệu suất kết quả của người dùng lớn đơn giản bởi NoSQL sinh ra để làm việc với những dữ liệu lớn, đa dạng và dễ dàng mở rộng dành cho lập trình viên. Nhưng trong những bài toán phức tạp và yêu cầu về rằng buộc lớn thì RDBMs luôn là xu thế được ưu tiên hàng đầu. Nếu ai bảo dùng RDBMs chậm thì bạn cứ thẳng thắn nói rằng trước năm 2009 khi NoSQL bùng nổ thì tốc độ lướt web của họ có chậm hơn so với bây giờ là bao không ?. Và tại sao ngân hàng vẫn chơi Java + oracle để dùng sao không dùng NoSQL để việc rút tiền nhanh thêm đi =)). Thực chất trước mình có tìm hiểu và biết rằng rất nhiều công ty lớn nó sử dụng song song 2 thằng này theo thứ tự: NoSQL làm việc với các client user, còn RDBMs thì là nơi backup dữ liệu. Việc sử dụng qua lại 2 thằng đảm bảo cho hệ thống vừa nhanh như gió và rằng buộc chắc chắn. Nhưng nếu chương trình của bạn là chuyên biệt và có tính năng quan trọng thì nên sử dụng RDBMs.

2, Việc bạn sử dụng loại dữ liệu nào cho những bài toán như này chỉ là một phần, Việc bạn thiết kế kiến trúc dữ liệu ra sao lại là 1 phần rất quan trọng. Ví dụ như này nhé:

Ta có cổ phiếu BUG giao dịch 1s sẽ cập nhật 1 lần vậy trong 1 ngày làm việc 8h ta có : *8 * 60 60 = 28.800 (record)

Bạn phải thực hiện tạo biểu đồ cho cổ phiếu đó theo thời gian biết rằng trong 1 record có trường date_time_update (datetime). Và có hàm getTime() (run -> 0.01ms)

vậy bây giờ bạn sẽ mất 28.800 * 0.01 = 288 ms = 0.288s để vẽ biểu đồ cho 1 cổ phiếu. Nếu có 100cp thì 0.288 s * 100 = 28.8s

Nhưng nếu thiết kế DB tốt hơn thì bạn sẽ thêm 1 trường time_update chính là thời gian của date_time_update và khi đó bạn sẽ tiết kiện được 28.8s thực thi tuy nhiên việc này sẽ đánh đối bằng dung lượng lưu trữ. Nếu time_update = 2byte / 1 record => 2880000 * 2byte = 5760000 byte = 5.76 MB.

Đây là 1 cách mình thường xuyên sử dụng với việc đánh đổi bộ nhớ lưu trữ lấy tốc độ của hệ thống. Ngoài ra trong khi code bạn sử dụng việc thao tác dữ liệu cho từng trường hợp sẽ nhanh hơn việc thao tác dữ liệu để dùng chung cho mọi trường hợp. Còn 1 vài trick mà mình đã sử dụng và tìm hiểu cũng hiệu quả lắm:

• Phân vùng những dữ liệu theo dạng Cũ - Mới, Thời gian, Địa lý, các thuộc tính đặc trưng,.... sử dụng where sẽ không làm cho tốc độ của bạn nhanh hơn thay vì thế hãy sử dụng bảng tạm để phân vùng dữ liệu (Tham khảo: https://www.red-gate.com/simple-talk/sql/database-administration/gail-shaws-sql-server-howlers/)

• Xóa dữ liệu cũ định kỳ: Dữ liệu cũ sẽ không thực sự bị xóa đi mà nó chỉ chuyển từ bảng A sang bản AHistory,..

• Thực hiệu lưu file nhị phân các hình ảnh tệp tin thay vì nhị phân chúng và lưu vào CSDL,....

Đó là 1 số cách mình đã từng và hay sử dụng ngoài ra nếu bạn muốn hiểu thêm có thể đọc 2 bài viết sau.

https://dba.stackexchange.com/questions/188667/best-database-and-table-design-for-billions-of-rows-of-data/188668

https://dba.stackexchange.com/questions/20335/can-mysql-reasonably-perform-queries-on-billions-of-rows