giúp tớ với!

[girlsky123]

Hic, giúp tớ với. Tớ làm chương trình bằng Visual Fox, nhưng khi chạy báo cáo mình sài Query hơi nhiều, chính vì thế nên lúc chạy báo cáo rất chậm thậm chí có lúc còn ko view nổi báo cáo. Có bạn nào biết cách nào làm tăng tốc độ view báo cáo ko? Dữ liệu của mình được để trên Servernt...Hic, chán thế ko biết? Ai biết thì chỉ cho minhvới...

[nguyenthu]

Bạn cho thêm bộ nhớ (RAM) là xong chứ gì ?
Còn nếu không đủ nhanh, bạn bớt quyền Access lại, chỉ cho vào những người nào thật cần thôi.
Còn sữa lại các Table thì không an-toàn lắm vì database đang xài.
Thân,

[girlsky123]

Hic, cam on ban, nhung cách nang cap RAM dó thi` chac ko on roi ? Boi vi` cau hinh` rat manh, duong truyen tren mang cũng ko có van de gi cả .Con` ve han che quyen truy cap thi` minh`da lam` roi ...hic, hic
Lieu co`n cách nao` ko ban ?
Giúp minh` voi nhé!

[nguyenthu]

Database của bạn gồm bao nhiêu tables ? và mỗi table bao nhiêu rows (tức record) ?
Tùy theo lớn nhỏ mà chọn hệ thống : Access (cũng như Fox), Oracle, DB2... mạnh hơn. Có dùng smartdrive ? hay virtual disk (đĩa ảo : thực ra là RAM thế cho đĩa trong khi chạy database).
Có update hay không ? Có kiểm soát là có thể bị dead lock hay không ?
Có nên làm index hay không ? v.v...
Có dùng quá nhiều function trong các câu query hay không ? Vì SQL đâu có mạnh về chuyện này.
Khi nào configuration tốt, đường truyền tốt, administration tốt, thì phải xem lại cách lập trình.
OK?

[girlsky123]

database cua to gom 8 table va` hon 1000 record , dung` function trong SQL thi` ko có nhieu va` hau nhu ko có, min`h chi truy van toi bang chính thọi Tat nhien la` dugn` index va` set relation de ket noi roi .
Nhung con` van de ma` ban noi :"có kiem soát la` có the bi dead LOCK hay ko ?" <---cái nay` ko hieu ?
Chinh vi` the nen minh` muon biet có chác nao` khac phuc hien tuong nay`kO ? NEU chi truy cap toi bang thi` dung` SQL trong các bao cao có sao dảu HIc, ....

[nguyenthu]

Vậy tôi xin giảng nghĩa cho bạn :
Thí dụ DB của bạn có hai tables, table1 và table2.
User1 vào viết (update, create) trên table1 và sau đó trên table2.
User2 vào viết (update, create) trên table2 và sau đó trên table1.
User1 vào trước, procedure của DB lock table1 và table2 (vì create và update), đang làm trên table1, User2 vào sau, đang làm trên table2 (lock table2 và table1).
Sau đó User1 thì muốn vào table2, nhưng nó đang bị lock bởi User2, còn User2 thì không vào được table1 vì nó đang bị lock bởi User1.
Nghĩa là người này chận người kia : đó là hiện tượng dead lock, không ai tiến hành được công việc.

Ðể tránh việc này :
1) Trong các chương trình có truy tới các table của db, phải có test về dead lock (thí dụ VB, Power Builder, cobol... đều có). Muốn thực hiện điều này, Admin về DB phải có quyền kiểm soát những chương trình chạy với DB của bạn, chỉ khi nào Admin cho phép thì chương trình mới chạy được.
2) Bạn làm việc, cần có một chương trình SQL Admin : cho bạn thấy tất cả những SQL Operations đang chạy, bạn thấy cái nào ở trên màn hình quá 5 phút thì bạn ngừng nó lại. Chương trình này có với DB2, nhưng mình không thấy có với Access.

Bạn chỉ có 8 tables và 1000 records thì ít, xài Access đủ rồi.
Bắt đầu trên 100.000 thì phải qua Oracle, và trên 1.000.000 thì phải qua những máy điện tính lớn (khoảng 4 Go RAM).

Hy vọng giúp được bạn.

NB : Bạn có nói là chỉ dùng Select để báo cáo có sao đâu, thật ra khi có User xin update, create, thì cơ chế của DB là nó lock hết tại vì sau khi update, create, informations sẽ đổi thay, cho nên dù là Select cũng sẽ nhận kết quả sai.

[girlsky123]

Cam on ban nhiẹu
Hic, dieu đó có nghĩa la` minh phai lam` lai bao cáo soa . The thi` om roi?

[past_beggar]

Thằng SQL Server sẽ bị deadlock (như đã giải thích) => đúng, có cách giải quyết rùi đấy thôi
Thằng Access, FoxPro chẳng thấy nói gì hay sao ấy => có thể chẳng bị deadlock đâu (bít đâu nó tự order thứ tự truy cập rùi)
Làm báo cáo lại là đúng, nhưng có thể truy vấn sành điệu quá, có vòng trong này, vòng trong nữa này ...v.v. Hè, làm phép tính nhân ma trận thấy hoảng quá trời

[girlsky123]

Hihi, ko phai dead lock gi` daU . Qua la` nan giai thiet , buc min`h ghe !

[past_beggar]

Nếu sử dụng mạng thì Uninstall cái client Microsoft là được.
Chúc vui.

[ptran]

8 tables và khỏang hơn 100 records thì là rất ít ... Theo tôi nghĩ thì là do viết program bên trong . Đôi khi không phải do query mà do có những vòng loop (while, for ...) làm cho chậm lại . Thử hiện giở trước và sau khi query data từ database ra xem tốn hết bao lâu để query . Nhiều người sau khi query data ra xong, dùng phương pháp while loop để đi từng record để tính tóan, save vô trong variables ... có thể chậm la do tại vậy . Ngoài ra, khi query không nên dùng "select *" . Delete object sau khi xài xong ...

Nhưng chậm là chậm như thế nào (bao nhiêu giây ?) ... cách đây 3 năm, database tôi dùng la khỏang hơn 30 tables với data khỏang 10000 records mỗi ngày ... thời gian để view một report (dùng ASP lấy data -> Crystal Report -> hiện lên trên web) là khỏang trung bình 20 secords . Report lam rất là detail (170 reports) mỗi cái dùng stored procedure khỏang 2000 lines . Boss tôi bảo là co`n chậm quá câ`n phải lam nhanh hơn .... Chậm nhanh tùy vô ngươ`i xem nua ... Với thơ`i gian 20 seconds thí` tôi biết là quá tốt rồi nhưng với ngươ`i xem thì đó là quá chậm . Tôi nghĩ là tôi có thể làm nhanh hơn được thêm vài giây cho mỗi report nhưng không đáng bỏ thời gian như vậy ...nếu có thể lam nhanh hơn khỏang 30 - 40 % thì nên làm ... nếu không thi không nên .

[nguyenthu]

Bạn ptran đã có góp ý kiến.

Xin kể cho các bạn chút kinh nghiệm :
- Select * (tức không có Where), trong một table 4.000.000 mất 5 phút (với máy điện tính IBM).
- Truy mỗi hàng khoảng 1/1000 - 1/100 giây, tùy theo có Update hay không, tùy table ?
- Có lần cần select với order by chừng 300.000 hàng, và kết quả là lâu quá, chịu không nổi, phải bỏ chương trình đó đi. Xin nhắc bạn nhớ, cái này là chương trình BATCH, có thể chạy 2-3 giờ cũng không sao, nhưng mà kết quả là không xong gì cả, phải ROLLBACK và RECOVER.

Tôi xin gợi ý thêm : "Bạn girlsky123 có xài order by hay không ?"
Nếu có thì có thể vấn đề nằm chỗ này, vì số operation là n ^ 2 / 2. Nếu có 1.000 hàng, thì số operation là 500.000.
Do đó, bạn cần sửa lại :
1) Database cần có Primary key để sắp xếp ngay từ lúc insert data.
2) Trong các Query, tránh bớt order by, bạn cần sắp xếp cột nào, thì làm index trên cột đó trước.
3) Nếu bạn làm chương trình, dùng DB thì cách mà người ta hay khuyên là :
- Select mỗi lần chừng 200-500 hàng mà thôi, tức là bạn dùng điều kiện
WHERE điềukiện BETWEEN trịgiá1 AND trịgiá2.
- Bạn mở một virtual table trong RAM, cho các hàng đó vào.
- Ðền khi tất cả các hàng cần thiết đã vào virtual table, lúc đó bạn xử lý.
Như vậy, bạn không dùng nhiều thì giờ connexion với DB, không xài nhiều đường truyền đến Server vì đường truyền cũng chậm (dù là mạng LAN), bạn xử lý trong RAM lẹ hơn nhiều.
Vấn đề này tôi cũng đã có bàn trên một vài forum, nhưng ý kiến của những bạn còn đi học khác hẳn với những tay chuyên-nghiệp.
Cố gắng chút nữa đi, sẽ thành công mà.

[girlsky123]

Vấn để khi xây dựng chương trình tớ dùng set relation để tạo mối quan hệ .
Cách xây dựng chương trình của tớ ko giống như cách khi đi học đã được đã được hoc . Mình chỉ sài query để làm bước đệm lấy dữ liệu theo ý muốn thôi và index chúng lại để tạo các báo cáo ,
Với hơn 10 bảng như hiện nay và data của nó càng ngày càng phỉnh lớn .cách tạo đường dẫn truy vấn đến data để trên server của mạng LAN .
Thì tớ đã khắc phục một số nhược điểm như nguyenthu và ptran đó, kết quả có khả quan hợn . Nhưng vấn để khi data còn quá ịt Nếu lớn quá thì có cách nào đó khắc phục nó như nén lại chẳng hạn, mình rất muốn viết một đoạn code để có thể nén dữ liệu lại ? Liệu có làm thế được ko ?
Nhưng quả thật sài query cũng mệt quá cơ ! Chắc phải chuyển hướng để làm báo cáo cho thuận tiện hơn .

[nguyenthu]

Ðã OK rồi đó.

Bạn nén file lại thì khi đọc, DB phải tự giải nén, lại càng mất nhiều thì giờ, cho nên chậm hơn. Do đó bạn đừng nén.

Ngoài ra, muốn cho DB chạy nhanh hơn nữa thì phải xem lại nhiều, bạn hãy tìm đọc những sách như "The performance SQL" hay những sách về loại này. Tôi có học sách này nhưng dùng cho DB2 với máy điện tính IBM.

Ðại loại nó giải nghĩa cơ chế làm việc của DB, thí dụ khi search thì nó theo cách phân hai (dichotomy search), nó đọc KEY, nếu không đúng trị giá của KEY muốn tìm thì nó nhảy sang record khác (mà không đọc tiếp các cột khác). Do đó tránh chọn KEY bằng type Datetime (26 ký tự)... Hay là cơ chế locking của DB, thí dụ mỗi page gồm 256 records, mỗi lần bạn update một record là nó lock trọn page, do đó không cần phải lock trọn table mà chỉ cần lock khoảng 200 records một lần là đủ...

Ngoài ra có nhiều DB, khi bạn xóa, nó không thật sự xóa (physique), chắc bạn biết. Do đó compact nó lại (tức là xoá hẳn những blank hay records đã xóa)...

Trong khung cảnh forum này, mình chỉ có thể kể lại chút kinh-nghiệm. Mong giúp bạn được chút đĩnh.

[Bacmaon]

Mình xin mạo muội ké tí:
Như Tiên nữ (hay Hằng Nga gì đó) nói là "dữ liệu càng ngày càng phình to ra", nếu như thế bạn đã bắt cái máy tính làm việc vất vả rồi, nếu dữ liệu của bạn có thể thì ngoài phân rã theo chiều dọc, bạn thử phân rã dữ liệu theo chiều ngang xem sao !
Thân !

[girlsky123]

Phân rã dữ liệu theo chiều ngang ???<-----------hihi, mình chưa hiểu ý của bạn lắm!

[bpmtri]

Phân rã dữ liệu theo chiều ngang ???<-----------hihi, mình chưa hiểu ý của bạn lắm!

Phân rã dữ liệu theo chiều ngang là bạn chia bảng thành nhiều bảng con, có cùng cấu trúc, nhưng chỉ chứa một phần dữ liệu của bảng khi chưa bị phân rã.

Ví dụ bạn có một bảng dữ liệu Customers có hàng trăm ngàn record, bây giờ để truy xuất được nhanh hơn, bạn chi bảng dữ liệu đó thành 26 bảng nhỏ, mỗi bảng chứa dữ liệu cho customers có tên bắt đầu bằng một chữ cái.

VD:
- Customsers_A chứa tất cả các customer có tên bắt đầu bằng chữ A
- Customsers_B chứa tất cả các customer có tên bắt đầu bằng chữ B
...

[past_beggar]

Nói thêm:
Trong thực tế các bảng nào có liên quan đến thời gian (bảng ghi nhật ký chẳng hạn) sẽ rất lớn và những dữ liệu có thời gian xa xa ít khi được dùng đến sẽ được partition thành một bảng history. Lúc thật sự cần mới lôi ra xài.

[girlsky123]

A, đúng rồi đấy, cảm ơn các bạn đã gợi ý cho tôi một ý kiến rất hạy Sao mình lại ko nghĩ ra nhỉ . Hihi, thanks you very much

[past_beggar]

A, đúng rồi đấy, cảm ơn các bạn đã gợi ý cho tôi một ý kiến rất hạy Sao mình lại ko nghĩ ra nhỉ . Hihi, thanks you very much

Bạn phải nói là sao mình không bít, sao mi`nh không nghĩ ra nghe có vẻ bác học quá hé hé hé

[girlsky123]

hic, làm gì mà vặn vẹo tớ từng câu từng chữ như thế hả Past_beggar .Dân IT mà ăn nói giống dân học văn quá nhỉ . Tớ cũng chỉ muốn học hỏi thôi chứ đâu có cái í mà ấy nói tớ thế à . Huhuhu!

[Bacmaon]

Lại một lần nữa cảm ơn bpmtri và past_beggar đã giải thích dùm (hôm trước mình quên).
Thân!