(Bài viết hoàn toàn mang tính chủ quan của tác giả, bạn có thể đọc, bình luận và ném đá nhưng hãy thực hiện các hành động đó với thái độ tôn trọng bản thân cũng như tôn trọng tác giả)
CÂU HỎI ĐƠN GIẢN, SUY NGHĨ PHỨC TẠP VÀ IMPLEMENT SAI BÉT NHÈ!
Như thói quen, mỗi khi nghe Mr.Tính hỏi bất kỳ câu nào, tôi đều im lặng, tay cho lên môi và rồi trầm ngâm như giai điệu vang lên trong đầu, một rồi hai đôi khi tận ba hay bốn. Câu trả lời đã có nhưng..
Sau đó Thầy lại hỏi cả lớp, "Thế mấy em có biết blob trong môn database là gì không?". Hừm, lại chả biết, em vừa mới đọc chuẩn bị cho team viết cách đây vài hôm mà.
Thế rồi, "Giữa việc lưu file ảnh hay file bất kỳ lên server chạy cho ứng dụng web thì tôi nên chọn lưu trên server's directories hay db?"
Vâng từ câu hỏi trên, nổ ra 1 tràng suy nghĩ giống như vụ bigbang bang rồi tận mấy tỉ năm sau vẫn còn big. In my case, that is a long story still happens in 4 or 5 weeks after that fucking question!.
Câu trả lời đầu tiên blob là một dạng dữ liệu cơ bản nhất mà hầu hết các hệ cơ sở dữ liệu sẽ hổ trợ để ghi file dưới dạng nhị phân, NHƯNG KHÔNG PHẢI TẤT CẢ CƠ SỞ DỮ LIỆU ĐỀU HỖ TRỢ BLOB đôi khi sẽ là một dạng khác, dễ gây ra tình trạng cân nhắc đến việc thay đổi kiểu dữ liệu sao cho phù hợp với từng cơ sở dữ liệu khác nhau!
Câu trả lời cho việc lưu file trên server's directories và lưu vào cơ sỡ dữ liệu cái nào tối ưu hơn thì chưa thể cân nhắc được nếu ta không được gắn cho một server cụ thể và trong một bài toán nhất định.
        + Giả dụ: ta có 1 server thuê của một bên thứ 3 đã được setup sẵn và cung cấp quyền truy cập như AZURE hay dịch vụ hosting nào đó. Thì hoàn toàn ta sẽ rất cực khổ vì AZURE sẽ được chia ra làm 2: 1 là chi phí đắt đỏ cho việc xin công khai thêm dung lượng lưu trên server deploy app, 2 là bài toán về backup dữ liệu sau mỗi lần reup lại phiên bản web app mới, cũng như phát triển thêm app và mở rộng cây thư mục, phiền phức và dễ đánh mất dữ liệu nếu không cẩn thận.
                -> Vì vậy, có thể nói về mặt tổng quan với trình độ non kém của tôi thì, trong th eo hẹp về kinh phí, kĩ năng deploy, sao lưu, và lên kế hoạch phát triển app kém thì nên lưu vào cơ sở dữ liệu.
                -> Thế lợi ích từ việc này là ntn ? thuê một server con tầm 10gb lưu trữ và vừa đủ cpu, ram cho việc lưu hình ảnh, file gọn nhẹ, tính sơ sơ thì cũng tiết kiệm kha khá, tinh ý thì có thể thuê cùng với nơi thuê server deploy web app tiện cho network round-trip khi truy vấn vào csdl, 1 tầng cache nhẹ cho các file có thể áp dụng LFU hoặc Timming Removing Map, tăng tốc độ(đương nhiên là sau này tôi đã có kinh nghiệm hơn sẽ có đánh giá tổng quan tốt hơn). Lúc đó backup data rất đơn giản dùng Hệ quản trị tương ứng với cơ sở dữ liệu đó để backup, rất khỏe, không sợ mất file, mất cấu trúc thư mục, bù lại tốn kha khá thời gian và bandwidth.
    + Giả dụ: ta có 1 vps khủng, planning tinh tường, nhìn thấu tương lai, kĩ năng backup, viết script thượng thừa thì lúc này nên cân nhắc việc lưu file trên directory, backup từng phần, backup theo phân đoạn, deplay time đủ các kiểu để tối ưu hơn cho việc backup.    
=> Tiện thế thì việc đọc, ghi file ảnh hưởng gì không nhỉ?
    - Trong th của mình, sử dụng ssd và lưu file trên localhost, mình có khoảng 8gb ảnh mà mỗi ảnh khoảng 100kb~1mb thì việc tìm 1 ảnh cũng ngốn khoảng 3-4s của mình, vì vậy phải xem xét tiếp về số lượng và dung lượng từng file vì về cơ bản cơ sỡ dữ liệu cũng là file, cũng bị chi phối về sức mạnh vật lý của ổ cứng, đến giới hạn sẽ chậm.(Indexing nếu sd cơ sở dữ liệu, đặt tên hợp lý có thể tăng tốc độ tìm file, sửa file, tái sử dụng thay vì phải up file và xóa file cũ đi đôi khi là giữ nguyên trên cấu trúc cây thư mục).
Tương thích của blob và cách giải quyết
Như đề cập ở trên blob không phải loại dữ liệu mà cơ sở dữ liệu nào cũng có, có một cách hay nói chính xác hơn sau đây là 1 trick để tạo sự tương thích khi export data ra sql query mà bất kỳ cơ sở dữ liệu nào import query đó vào đều chạy được là : "Sử dụng kĩ thuật encode với base64 chuyển một mảng byte thành một text mà text thì anh cơ sở dữ liệu nào cũng có và max length có thể lên đến và đôi khi hơn 4000 thực sự quá dư thừa cho việc lưu trữ ảnh hay chỉ mặt gọi tên nó là MIME content transfer encoding(wiki đê đợi gì nữa hả cậu!)"
Lý thuyết là vậy, what about thực hành ?
Trước tiên ta có file, dùng binary input đọc file đó thành 1 mảng byte, sau đó đi qua base64 encoder, đem đoạn text đó lưu xuống csdl. Khi cần thì từ csdl đọc text lên và ngược lại base64 trả về mảng byte. Từ mảng byte đó xây lại file.
=> Nhược điểm 1, tiêu tốn khá nhiều cpu nếu thao tác ghi, đọc file xảy ra nhiều trong th không có tầng cache.
=> Nhược điểm 2, tiêu tốn dung lượng ổ cứng vì khi đi qua base64 là quá trình chuyển 1byte binary sang 1 digit byte với 6 bit là binary data và 2 bit là padding nên cơ bản là sẽ gia tăng dung lượng ổ cứng lên ít nhất là 25% hoặc hơn..Tìm hiểu sau do tôi chưa tìm hiểu tường tận về base64
=> Nhược điểm 3, nếu không tường tận việc đọc,ghi file cũng như tiền xử lý file rất dễ ăn hành và tôi đã ăn hành như thế nào, câu chuyện còn được tiếp tục ở chương sau: "LTM đến LTW, sai lầm về lưu file base64 cũng như ăn hành sml về ghi file string không qua encode"