Các bác có query sql kiểu này không?

Agatha Christie · 1/4/21

mmmmmm2 đã nói:
ORM chỉ được cái tiện dụng, mì ăn liền thôi.
Về cơ bản, khi dùng ORM thím phải thực sự hiểu nó chạy như thế nào thì mới dùng tốt được.
Chỗ em ưu tiên dùng raw sql, thím nào bảo khổ dâm thì em cũng chịu nhưng product mà kiến trúc được xây dựng 20 năm rồi, giờ vẫn chạy phà phà, ko có dấu hiệu chậm đi theo năm tháng.

Thôi thôi, product hiện đang làm cũng lauching trên cloud dc hơn 10 năm rồi, có cả ngàn client vs số lượng request lên đến cả triệu request/h trên UI, chưa tính background process vẫn dùng ORM ầm ầm. Tiêu chí review code vẫn ưu tiên criteria vs hql trước, nào code k dc mới viết sql thuần. Dĩ nhiên là phải hiểu rõ mới dùng chứ k phải dùng tùm lum, perf lâu lâu cũng có nhưng tìm cách optimize mapping, ERD chứ k phải bằng cách viết raw sql :go:

. Mấy process lớn thì đưa vào procedure luôn :go:

Xưa từng vào 1 project viết sql 100%, code duplicate tùm lum, mạnh ai ng đó viết k có 1 chuẩn gì hết, tởm quá out ngay trong tháng thử việc luôn :whistle:

Agatha Christie · 1/4/21

tiktik2190 đã nói:
gặp cái table mấy trăm field thì ăn cám à, select cái nào cần thôi

Table mà mấy trăm field thì chứng tỏ cái thằng thiết kế db như hạch, thím có thể tìm chân trời khác mà học hỏi đi là vừa :go:

Sn0wIce · 1/4/21

Select * ...Ăn ngay KPI chứđùa

111911 · 1/4/21

tôi theo trường phái thêm cả logic vào sql luôn. query cái là sài luôn xử lý trên code rất ít.

Gowther · 1/4/21

Có blob query chậm vl. Tốt nhất là dùng gì lấy đó

zAries · 1/4/21

Donald Trump USA_No1 đã nói:
Ví dụ em chỉ cần lấy ra 1 vài cột của 1 record, nhưng em thường lười viết hàm chung lấy toàn bộ (select * ) cột đó ra rồi dùng đi dùng lại trong toàn ứng dụng

Mình nghĩ việc này không ảnh hưởng performance mấy, anh em nghĩ sao?

muốn thằng lead vào combo không mà query kiểu đó ? làm chức năng gì lấy cái gì query cái đó , lỡ table có 100 row mà select kiểu đó get tầm 100000 records thì trối chết

bigpig245 · 1/4/21

Mấy thím viết sql thấy có vẻ pro biết bao nhiêu mà k phân biệt dc nổi column, row, record mà dùng tùm lum vậy.
Table mà lên đến cả trăm column thì thôi bỏ tiền ra thuê 1 thằng DBA xịn về nó optimize ERD cho, còn k thì kiếm chỗ khác dành tg làm cái khác ngon hơn, đừng khổ dâm viết sql thuần tối ngày nữa, mấy cái select đó k improve dc tí gì kỹ năng viết sql của các thím đâu, tốn tg code thôi.

maiyeuweb · 1/4/21

Agatha Christie đã nói:
Thôi thôi, product hiện đang làm cũng lauching trên cloud dc hơn 10 năm rồi, có cả ngàn client vs số lượng request lên đến cả triệu request/h trên UI, chưa tính background process vẫn dùng ORM ầm ầm. Tiêu chí review code vẫn ưu tiên criteria vs hql trước, nào code k dc mới viết sql thuần. Dĩ nhiên là phải hiểu rõ mới dùng chứ k phải dùng tùm lum, perf lâu lâu cũng có nhưng tìm cách optimize mapping, ERD chứ k phải bằng cách viết raw sql . Mấy process lớn thì đưa vào procedure luôn
Xưa từng vào 1 project viết sql 100%, code duplicate tùm lum, mạnh ai ng đó viết k có 1 chuẩn gì hết, tởm quá out ngay trong tháng thử việc luôn

Làm mấy nghề như kế toán mà xử lý dữ liệu nhiều nên học thêm gì ngoài vba bác nhỉ ?

bboyz269 · 1/4/21

Ảnh hưởng thời gian read/transfer data thôi. Chứ performance của query phục thuộc vào where, join, sort ... đồ nhiều hơn.
Mỗi DB đều có tool để estimate cost của query đó, tìm hiểu thử đi bạn.

lmnt · 1/4/21

Agatha Christie đã nói:
Table mà mấy trăm field thì chứng tỏ cái thằng thiết kế db như hạch, thím có thể tìm chân trời khác mà học hỏi đi là vừa

thế bác lại bảo thằng thiết kế db của M$ như hạch à
đụng db của Dynamics AX chưa, toàn cả trăm field ấy

mà table của nó cũng mấy trăm

mmmmmm2 · 1/4/21

lmnt đã nói:
thế viết store xong orm gọi ra vẫn lợi hơn chứ nhỉ
trong BE thì code đẹp, dev cũng dễ hiểu

Store procedure thì nó bị phụ thuộc vào DBMS, khó control thím ạ.

Agatha Christie đã nói:
Thôi thôi, product hiện đang làm cũng lauching trên cloud dc hơn 10 năm rồi, có cả ngàn client vs số lượng request lên đến cả triệu request/h trên UI, chưa tính background process vẫn dùng ORM ầm ầm. Tiêu chí review code vẫn ưu tiên criteria vs hql trước, nào code k dc mới viết sql thuần. Dĩ nhiên là phải hiểu rõ mới dùng chứ k phải dùng tùm lum, perf lâu lâu cũng có nhưng tìm cách optimize mapping, ERD chứ k phải bằng cách viết raw sql . Mấy process lớn thì đưa vào procedure luôn
Xưa từng vào 1 project viết sql 100%, code duplicate tùm lum, mạnh ai ng đó viết k có 1 chuẩn gì hết, tởm quá out ngay trong tháng thử việc luôn

Rõ ràng em cũng nói là hiểu rõ mới dùng tốt được mà.
Ngay cả stackoverflow cũng phải từ bỏ Linq2SQL của MS để viết lại Dapper nhằm mục đích là dễ dàng sử dụng được SQL song song với ORM.
Chuyện thím vào 1 project viết sql 100%, code duplicate tùm lum rồi dẫn đến ác cảm với SQL thì em cũng hiểu, nhưng nếu thím vào 1 dự án được thiết kế bài bản ngay từ ban đầu thì có thể thím sẽ nghĩ khác đi.
Ngày xưa lúc mới dùng ORM chuyển sang 1 dự án SQL thuần cũng thấy khổ dâm thật, nhưng làm lâu mới thấy nó bá đạo.

)

trunglq · 1/4/21

biendond đã nói:
Rows hay columns
Hơn 200 columns chứng tỏ thiết kế db như...

cols bác. Nãy đói quá viết nhầm

Agatha Christie · 1/4/21

maiyeuweb đã nói:
Làm mấy nghề như kế toán mà xử lý dữ liệu nhiều nên học thêm gì ngoài vba bác nhỉ ?

Xử lý dữ liệu kiểu gì thím, python nếu thím muốn theo data science nhen

lmnt đã nói:
thế bác lại bảo thằng thiết kế db của M$ như hạch à
đụng db của Dynamics AX chưa, toàn cả trăm field ấy
mà table của nó cũng mấy trăm

Chả lẽ cứ DBA của MS là ngon? Nhiều khi nó thiết kế tệ từ đầu và dùng quá lâu rồi nên k ai dám optimize thôi chứ thực tế tệ thì vẫn tệ thôi. Với cả db chuyên về report nó lại mảng khác tôi k rành. Nếu làm chuyên về report, query nó đã lên tầm cỡ join mấy chục bảng thì việc select nó có ý nghĩa. Còn vs 1 product CRUD bình thường, việc select 1 vài item nó chả có ý nghĩa gì hết, chỉ làm tăm tối thêm cho source code, tốn thời gian làm thôi.
Từng support 1 case query làm insight report, câu query dài chắc phải 2 trang giấy A4, chạy gần tiếng k xong và bọn nó bảo query bọn nó chạy vậy là bt. Chán k buồn nói.

conclave0 · 1/4/21

Donald Trump USA_No1 đã nói:
Ví dụ em chỉ cần lấy ra 1 vài cột của 1 record, nhưng em thường lười viết hàm chung lấy toàn bộ (select * ) cột đó ra rồi dùng đi dùng lại trong toàn ứng dụng

Mình nghĩ việc này không ảnh hưởng performance mấy, anh em nghĩ sao?

Cố gắng đừng lấy *, lấy những thứ cần thôi. Nó liên quan nhiều đến performance. Gặp table có 200 columns là chết. Với chuyện không ảnh hưởng performance là sai. Khi table, db của bác đã tuning performance (index, partition, ...) thì nhiều người sẽ nhắm đến tuning query.

Agatha Christie đã nói:
Table mà mấy trăm field thì chứng tỏ cái thằng thiết kế db như hạch, thím có thể tìm chân trời khác mà học hỏi đi là vừa

Nghe bác nói thì có vẻ là chưa đụng vào db của ngân hàng, hoặc các tổ chức tín dụng, bảo hiểm, ... những table lớn của đám này có từ 150 - 300 columns là chuyện bình thường.

funspark247 · 1/4/21

cứ dùng tẹt ga nhé, nhưng mà lúc phỏng vấn thì đừng có nói thế, ko là toạch đấy

lmnt · 1/4/21

Agatha Christie đã nói:
Xử lý dữ liệu kiểu gì thím, python nếu thím muốn theo data science nhen

Chả lẽ cứ DBA của MS là ngon? Nhiều khi nó thiết kế tệ từ đầu và dùng quá lâu rồi nên k ai dám optimize thôi chứ thực tế tệ thì vẫn tệ thôi. Với cả db chuyên về report nó lại mảng khác tôi k rành. Nếu làm chuyên về report, query nó đã lên tầm cỡ join mấy chục bảng thì việc select nó có ý nghĩa. Còn vs 1 product CRUD bình thường, việc select 1 vài item nó chả có ý nghĩa gì hết, chỉ làm tăm tối thêm cho source code, tốn thời gian làm thôi.
Từng support 1 case query làm insight report, câu query dài chắc phải 2 trang giấy A4, chạy gần tiếng k xong và bọn nó bảo query bọn nó chạy vậy là bt. Chán k buồn nói.

oh

vậy thì quá pro rùi
tôi đề nghị bác liên hệ vs M$ gấp để xử lý giúp nó
khéo thành tỷ phú ấy

vothevinh · 1/4/21

quan điểm của tui là: "premature optimization is the root of all evils". Optimize cái gì cũng có trình tự với phương pháp của nó. Cứ select * thoải mái, cho tới khi gặp performance trong SQL thì analyze nó rồi đánh index (thiếu gì cách để check nhỉ), nếu đánh index rồi mà nó vẫn chậm do nhiều column quá thì lúc đó mới hạn chế column lại, còn nó vẫn chậm thì lúc đó mới tính tới chuyện cache này nọ.

mà hầu như đoạn đánh index là nó giải quyết được kha khá trường hợp rồi.

vozer_2020 · 1/4/21

Không nên, data to tổ bố thì treo ngay, chỉ lấy những thứ cần thôi. Đến cả lệnh Join còn có left-join cơ mà

tanpro90 · 1/4/21

biendond đã nói:
Rows hay columns
Hơn 200 columns chứng tỏ thiết kế db như...

ít nói để người ta tưởng mình ngu thôi !!! đừng nói ra cho ng ta khẳng định vậy chớ !!!

Agatha Christie · 1/4/21

lmnt đã nói:
oh vậy thì quá pro rùi
tôi đề nghị bác liên hệ vs M$ gấp để xử lý giúp nó
khéo thành tỷ phú ấy

Thôi, méo nói chuyện vs mấy thím đi tôn thờ mấy cái ERD ngu học mấy trăm columns nữa

)))

Các bác có query sql kiểu này không?

Senior Member

Senior Member

Member

Senior Member

Junior Member

Senior Member

Đã tốn tiền

Senior Member

Senior Member

Đã tốn tiền

Junior Member

Member

Senior Member

Senior Member

Senior Member

Đã tốn tiền

Senior Member

Senior Member

Senior Member

Senior Member

Chủ đề tương tự

Thống kê chủ đề

Chia sẻ trang này