Các bác có query sql kiểu này không?
- Người tạo chủ đề Donald Trump USA_No1
- Ngày bắt đầu
funspark247
Senior Member
200 col là quá nhiều, còn 200 row là quá ít
sudo rm -rf sudo
Junior Member
100 triệu records chắc ngồi ngủ được giấc đó bác.
tanpro90
Senior Member
tùy thiết kế , tùy mục đích
các DWH lớn thì bảng vài trăm cols là bình thường, vài tỉ hay vài chục tỉ row cũng đầy rẫy
1 bảng vài chục TB cũng có luôn !!!
khẳng định chắc nịch 1 bảng vài trăm cols là quá nhiều thì chắc chưa gặp bao giờ rồi
hoacnguyengiap
Đã tốn tiền
Trừ db có những column data lớn như kiểu article body, còn bình thường cứ select all convert ra dto mà làm.
Ai mà còn lăn tăn performance select* trên những db mà toàn column nhỏ thì chắc chắn là chiếu mới
Những trường hợp như vậy performance gain không đáng là bao, công sức update query hay dto khi cần thiết mới là đáng kể
Ai mà còn lăn tăn performance select* trên những db mà toàn column nhỏ thì chắc chắn là chiếu mới
Những trường hợp như vậy performance gain không đáng là bao, công sức update query hay dto khi cần thiết mới là đáng kể
daizalangthang
Junior Member
funspark247
Senior Member
có design bao giờ chưa, nhét hết vô 1 bảng thì ai lại dùng Relational database
DekIu
Senior Member
200 columns thì đúng là thằng thiết kế db như bùi thật.
cơ mà các pmem erp của nước ngoài hay các pmem ktoan to to của vn thì ở table chính (mình hay gọi là sổ cái) cũng ngót 100 columns
tanpro90
Senior Member
em lạy anh !!! mấy cái core bank hay core DWH em từng làm đều là mua của nước ngoài chứ em làm éo gì đủ level để tự thiết kế mấy cái đó
còn chuyện nhét hết vô 1 bảng thì k đúng . do cái bảng đó nó cần thiết phải thiết kế như vậy và nó có ràng buộc rõ ràng . thông tin trong đó là cần thiết.
với lại "nhét hết vô một bảng" ý anh là sao ?? nhét data hay nhét cấu trúc??
data thì nó vài chục TB 1 bảng là bình thường . có gì lạ đâu anh
anh chưa thấy DB nào như thế thì k có nghĩa là nó ko có ./
funspark247
Senior Member
tôi cũng làm đủ loại banking rồi anh, dùng relational db thì cái éo gì cũng tách ra nhiều bảng được hết nhé, còn trường phái gộp hết vào chung 1 bảng/object thì người ta hay dùng nosql để store dưới dạng object
conclave0
Senior Member
Có thể bác chuyên về Program, bác nói CRUD chọn thằng nào cũng dc, quất thằng nào cũng xong, thì ok.
Còn khi mang vấn đề Database ra, bác nói DB của MS thiết kế tệ thì thật tôi cũng chẳng dám tranh cãi với bác nữa. MS hiện đang là top 3 cloud provider lớn nhất thế giới (MS, Google, AWS).
Người ta đang bảo build DWH, ông lại vác RDB vào? DHW vì muốn tối ưu query time nên mới nhét hết vào một table. Mời ông đọc Consolidate Fact
Mình còn sẵn data dictionary của 1 công ty bảo hiểm nổi tiếng. Table lớn nhất chứa 257 columns. Họ chấp nhận dồn những column của bảng khác vào bảng này, để không phải join nhiều khi query.200 columns thì đúng là thằng thiết kế db như bùi thật.
cơ mà các pmem erp của nước ngoài hay các pmem ktoan to to của vn thì ở table chính (mình hay gọi là sổ cái) cũng ngót 100 columns
huycon1002
Senior Member
Tiện đây ae cho hỏi có cách nào để tách db SQL SERVER ra thành 2 máy chủ vật lý khác nhau đồng bộ dữ liệu realtime ko?
1 máy tác vụ thêm sửa xóa
1 máy đọc dữ liệu
1 máy tác vụ thêm sửa xóa
1 máy đọc dữ liệu
biendond
Senior Member
Nhờ bạn giải thích giúp mình việc thiết kế 200 columns là khôn với.
Người khôn thì nên tranh luận có luận điểm bạn ạ
thanhcongmms
Senior Member
thím tìm hiểu từ khóa load balancing ấy -> tiếng việt là cân bằng tải.
funspark247
Senior Member
có cái SQL server replication đó thím
conclave0
Senior Member
Vậy 1 câu select 100 column từ 1 table 200 column và 1 câu select 100 column từ 10 table 20 column, thì bác cho mình hỏi cái nào nhanh hơn?Nhờ bạn giải thích giúp mình việc thiết kế 200 columns là khôn với.
Người khôn thì nên tranh luận có luận điểm bạn ạ
thanhcongmms
Senior Member
dạo qua diễn đàn các thím thấy chê SQL thuần rồi nâng bị ORM nhỉ ,
hỏi ngu tí: thế ORM nó không phải dịch đống code java ra câu SQL để làm việc với DB à,
select * là điều hạn chế ko nên dùng nhé thím thớt, còn thằng nào thích thì cứ dùng cũng chẳng ai cấm đc
, hỏi ngu tí: thế ORM nó không phải dịch đống code java ra câu SQL để làm việc với DB à
,select * là điều hạn chế ko nên dùng nhé thím thớt, còn thằng nào thích thì cứ dùng cũng chẳng ai cấm đc
Hướng Đối Tượng
Member
ko quan trọng nhanh hay chậm, đúng là được ) thế ae sau mới có việc mà maintain chứ
) thế ae sau mới có việc mà maintain chứ
funspark247
Senior Member
ORM apply nhiều vô mấy cái dự án mono thôi, microservice thì cứ ốp thằng query thẳng vào, chạy max nhanh, code cũng khỏedạo qua diễn đàn các thím thấy chê SQL thuần rồi nâng bị ORM nhỉ
hỏi ngu tí: thế ORM nó không phải dịch đống code java ra câu SQL để làm việc với DB à
select * là điều hạn chế ko nên dùng nhé thím thớt, còn thằng nào thích thì cứ dùng cũng chẳng ai cấm đc
mà ở việt nam chưa biết về microservice nên vẫn còn chuộng orm lắm
Mr.Almighty
Đã tốn tiền
Muốn được cái này thì phải chấp nhận mất cái kia. Có thế cũng tranh cãi.
Bảng nhiều cột thì code mệt, sửa mệt nhưng tốc độ nó hơn là đi join. Cần cái nào thì áp dụng cái đó thôi.
Bảng nhiều cột thì code mệt, sửa mệt nhưng tốc độ nó hơn là đi join. Cần cái nào thì áp dụng cái đó thôi.
Chủ đề tương tự
