Về khóa chính không bắt đầu từ 1

[Kiều Mạnh]

Access Tôi không biết nhiều lắm và chỉ xem nó như là File Data.accdb lưu trữ dữ liệu và tạo các mối quan hệ của các bảng dữ liệu ( Ở mức cơ bản, đơn giản nhất thôi ... còn phức tạp là tôi Tịt)

Tôi có vài ý nêu ra như sau với mục đích tìm hiểu thêm thôi

1/ tại sao phải bắt đầu từ con số 52 =??!!!

2/ khi trường ID là AutoNumber có nghĩa nó sẻ tự động tăng dần lên vậy khi ta nhập sai gì đó mà xóa các dòng ở khúc giữa thì sao ???!!! giá trị tăng dần không còn chính xác nữa

3/ tại sao không cho trường ID là Number thì nó cũng thế thôi mà thuận tiện khi xử lý nhiều kiểu dữ liệu khác nhau tốt hơn

4/ khi kiến thức khá lên ta có thể Úp cái File Data.accdb lên Web Server của chính mình thì khi truy xuất dữ liệu từ xa như mục số 3 nó ít lỗi và dễ xử lý hơn mục số 2 ( Còn phân tích tại sao thì tôi chịu ... vì tôi thử mọi cái nó thế )


5/ VD: khi ta chèn dữ liệu theo mục số 3 thì nó sẻ tôt hơn mục số 2 mà không bị lỗi ... còn tại sao thong thả dò là ra thôi

sử dụng phương thức Append

Rs.Fields.Append "AffectedRows", vbLong
Rs.Open: Rs.AddNew Array(0, 1), Array(Cnn.Execute("Select @@Identity")(0), AffectedRows)

... rảnh bà tám tiếp

 

[Vô danh Tiểu tốt]

Vậy thì theo cách ở bài 16 copy ở trên paste xuống dưới ID vẫn bắt đầu bằng 11 nhưng dòng dữ liệu nhập vào đầu tiên hồi năm ngoái sẽ mang số 25 (như phát hiện của bài 17). Tôi không quan tâm vì yêu cầu chỉ nói về ID bắt đầu từ 52 chứ không nói gì về nguyên dòng dữ liệu đầu tiên phải mang số 52.

Và theo tôi thì nó mang số 52 hay 152 hay 1000 chả ảnh hưởng gì đến việc nhập liệu, ra báo cáo, ....

Để tôi đối chiếu "niềm tự hào" của ptm0412 với kết quả mà theo thôi là hợp lý hơn với hình minh họa bên dưới. Sự hợp lý ở đây chính là thứ tự trước sau của các dòng dữ liệu vẫn tương tự như ban đầu, giúp cho người quản lý dữ liệu dễ dàng nắm bắt và cũng để đảm bảo những ràng buộc khi không thể tùy tiện phá vỡ thứ tự các dòng dữ liệu. Giải quyết theo hướng hợp lý này cũng không quá khó với nhiều anh chị ở đây.

Nhân đây tôi cũng giới thiệu một giải pháp của các anh Tây có thể giúp nhảy cóc bộ đếm của Autonumber đối với bảng đã tồn tại. Cách này chỉ áp dụng nếu không có relationship. Lưu ý là cách này đòi hỏi số dòng dữ liệu đã được nhập vào (kể cả đã xóa) phải ít hơn...

ALTER TABLE TableThatIncrements
   ALTER COLUMN Id AUTOINCREMENT(52,1)

 

[ptm0412]

Để tôi đối chiếu "niềm tự hào" của ptm0412

Nếu đọc kỹ sẽ thấy tôi tự hào vì cái gì. Không phải tự hào về kiến thức nhá.


Tôi thực nghiệm theo ý của tôi, và ý của tôi dựa trên yêu cầu mà tôi cố tình viết chữ đậm:



Và tại sao tôi bỏ qua việc copy xong bị chạy số khác thì đã giải thích ở bài 20.

Tôi sẽ không nói gì thêm, và đừng gọi tên tôi nữa.

 

[Vô danh Tiểu tốt]

View attachment 296315

Như ông chú nói "Tội tự hào là người luôn thực nghiệm ...". Thay vì dùng từ "thực nghiệm", tôi dùng từ "niềm tự hào" như là cách ví von những gì chú đã làm theo đúng tinh thần mà ông chú phát biểu.

 

[ptm0412]

Như ông chú nói "Tội tự hào là người luôn thực nghiệm ...". Ông chú thấy tự hào với việc mình làm nhưng thành quả của nó thì ông chú lại không có cảm xúc tương xứng là sao nhỉ? Nếu Messi phát biểu "Tôi tự hào vì thi đấu cùng đội tuyển tại Worldcup 2002 nhưng không tự hào vì chiếc cúp vô định (thành quả)" thì chú có thấy lời nói anh này có gì bất nhất không?

Đọc lại dòng chữ đậm và nguyên bài 20. (nhắc lần 2, để không đọc hoặc đọc không hiểu, hoặc cố tình vặn vẹo). Tôi hết!

 

[VetMini]

Đọc lại dòng chữ đậm và nguyên bài 20. (nhắc lần 2, để không đọc hoặc đọc không hiểu, hoặc cố tình vặn vẹo). Tôi hết!

Theo tôi thì Access được ra lúc máy tính còn yếu. Mà máy yếu thì chạy CSDL LH thật chuẩn sẽ sặc gạch. Do đó phiên bản cũ của Access thường né chuẩn một chút bằng cách đặc chế một số luật mà CSDL LH ngày nay không thấy. Nhiều luật thấy rõ ràng rằng do ràng buộc với loại file ISAM, VSAM (random access), Sequential.
Các loại CSDL mới hơn (SQL Server, mySQL, Oracle,...) dễ chỉnh sửa metadata là vì chúng dùng loại files mới hơn (điển hình là Index bằng B-Tree)

Do Access phải hỗ trợ các phiên bản cũ cho nên nó có nhiều chỗ uất nghẹn.

 

[Vô danh Tiểu tốt]

- Trường autonumber chả có ý nghĩa gì về mặt dữ liệu (không chứa thông tin), nó cũng không hiện diện trên form nhập liệu, báo cáo. Người dùng cuối có khi còn không biết đến sự tồn tại của nó. Vậy thì dù nó là bao nhiêu cũng chẳng cần biết làm gì.

Một trường dữ liệu được chọn làm key mà chả có ý nghĩa về mặt dữ liệu? Với người biết cách dùng, nó không khác gì "vân tay" của dữ liệu và cho nhiều thông tin hơn là chỉ là một cái mã.

- Nếu xóa 1 record mang số ID nào đó, thì số đó mất vĩnh viễn, những số ở dưới không đôn lên. Thì không còn tính liên tục để nhìn cho đẹp mắt.

Trước khi tham gia cái chủ đề này, tôi cũng tưởng là như thế nhưng sau nhiều thử nghiệm thì tôi phát hiện ra là không phải. Với Autonumber chả có gì mất vĩnh viễn cả, một giá trị bị xóa đi dùng lại hoàn toàn bình thường, ít nhất là với Access 365. Và nếu dùng lại một giá trị Autonumber từng bị xóa thì sẽ xẩy ra một điều rất thú vị. Tôi đã thử nghiệm một lần nữa trước khi đưa ra ý kiến này và cũng đã thử vài ba lần trước đó vì không thể tin vào sự thật.

Hy vọng là sau khi tiết lộ cái thông tin bất ngờ này, nhiều anh chị có hứng thú với database cũng sẽ táy máy để tự khám phá điều tôi vừa chia sẻ. Và nếu đúng như tôi đã nói thì đừng ngại phản hồi nhé.

 

[VetMini]

Không ai bắt buộc CSDL LD phải chuẩn tới mực nào cả.
Chuẩn ở đây là dịch từ "normalisation" (không phải tôi tự dịch, và tôi thích viết tiếng Anh thay vì tiếng Mẽo). Nó chỉ dùng để dễ nắm đầu dữ liệu thôi. Cũng như bảng tính Excel nếu thiết kế đàng hoàng thì dễ làm việc.
Ví dụ để lập master file cho kiểu đóng gói gồm gói, thùng, pa-let, cần xé,... người ta có thể dùng 2 ký tự đầu để làm khóa id: go, th, pl, cx,... Người đọc quen sẽ tự đoán được kiểu từ key. Lúc liệt query ra, không cần phải từ transaction lấy khóa ngoại (cái key trên) kết nối (join) master file để biết kiểu. Ai cũng vui vẻ.
Rất tiếc, đến một ngày đẹp trời nào đó, kiểu đóng gói sanh thêm cái "thúng". Vậy thì key nó là gì đây? Đặt là ts? Người đọc lại phải tập hiểu s liên quan đến dấu sắc. Tuy rằng họ sẽ thắc mắc tại sao thùng lại khong dùng cái gì liên quan đến dấu huyền!

Kiểu tra cứu mã để tìm ra liên hệ là kiểu thượng cổ mà chỉ có mấy người giáo viên không chạm thực tế mới còn giữ.
"hai ký tự đầu là loại hàng, ký tự giữa là số nhà kho, ký tự cuối cùng cho biết..." ---> rác rưởi!

Chú thích:
Trên thực tế, người ta hy sinh một bậc chuẩn để tăng tốc là chuyện thường tình. Nhưng khi làm chuyện đó người ta biết là mình có "hy sinh", chứ không hề nói là "làm vậy mới đúng".

 

[ongke0711]

Trên thực tế, người ta hy sinh một bậc chuẩn để tăng tốc là chuyện thường tình. Nhưng khi làm chuyện đó người ta biết là mình có "hy sinh", chứ không hề nói là "làm vậy mới đúng".

Đúng vậy bác. Tôi cũng thường dùng cả 2 kiểu tạo khoá chính. Chỉ dùng cách tạo mã bằng việc kết hợp thông tin cho một số bảng dữ liệu có tính đặc trưng, còn lại các bảng dạng lưu record chi tiết (như chi tiết hoá đơn, chứng từ nhập xuất ...), số record lớn thì cứ dùng Autonumber làm khoá chính. Khỏi tốn code tạo mã, index, tìm kiếm khoá dạng số cũng nhanh...
Từ đó đến giờ thiết kế CSDL xong đưa vào hoạt động cũng chẳng có lý do gì phải code tái sử dụng lại các mã dùng Autonumber đã xoá. Dữ liệu nào nhập sau thì cứ nằm sau, chẳng có lý gì để chen vô sâp xếp trước vì tái sử dụng Autonumber (ANum) cũ. Còn có một trường hợp thực tế khác là khi nhập liệu dòng mới, mã với ANum tự động tạo -> sau đó lại xoá record đó do sai một số thông tin, tạo lại -> ANum sẽ tự động gán số mới mặc dù số liền kề trước đó chưa được dùng (do mới bị xoá). Muốn lấy lại số liền kề trước đó thì chỉ việc chạy Compact and Repairt Databae là Anum sẽ trả lại số mới nhất liền kề. Tôi thường dùng cách này khi bàn giao ứng dụng cho khách, xoá toàn bộ dữ liệu nháp, reset Autonumber về lại 1.