mysql - có bao nhiêu cột là quá nhiều?

111

Tôi đang thiết lập một bảng có thể có tối đa 70 cột. Bây giờ tôi đang nghĩ đến việc tách nó ra vì một số dữ liệu trong các cột sẽ không cần thiết mỗi khi truy cập bảng. Sau đó, một lần nữa, nếu tôi làm điều này, tôi sẽ phải sử dụng các phép nối.

Tại thời điểm nào, nếu có, nó được coi là quá nhiều cột?

sql mysql

— Brad
nguồn

6

Chúng ta không phải sử dụng SELECT * mọi lúc. Chúng tôi luôn có tùy chọn để chỉ chọn các cột chúng tôi cần cho một tình huống nhất định.

— APC

3

70 cột ?! Có bao nhiêu trong số đó không thể là rỗng?

— OMG Ponies

1

Câu hỏi lớn là ... bạn có đang bình thường hóa các bảng của mình không? 70 là một số tiền bất thường trừ khi bạn đang cố tình không chuẩn hóa cho hiệu suất (rất ít thứ có 70 thuộc tính duy nhất). Nếu bạn đang không chuẩn hóa vì lợi ích của hiệu suất thì tôi đồng ý với ChssPly76 rằng bạn có thể sử dụng bất kỳ thứ gì mà cơ sở dữ liệu cho phép bạn sử dụng.

— Godeke 24/09/09

2

@KM. đó có phải là một trò đùa? Tôi là người mới sử dụng MySQL và không thể hiểu được nó, ý của bạn là THAM GIA là một điều tốt hay điều gì đó cần thử và tránh?

— Elia Iliashenko

2

Cũng giống như các phép nối là một phần cốt lõi của SQL, việc tham gia vì mục đích tham gia có thể sẽ làm giảm hiệu suất và khả năng bảo trì cho bất kỳ ứng dụng nào bạn có.

— jeteon

142

Nó được coi là quá nhiều khi nó vượt quá giới hạn tối đa được cơ sở dữ liệu hỗ trợ .

Thực tế là bạn không cần mọi cột được trả về bởi mọi truy vấn là hoàn toàn bình thường; đó là lý do tại sao câu lệnh SELECT cho phép bạn đặt tên rõ ràng cho các cột bạn cần.

Theo nguyên tắc chung, cấu trúc bảng của bạn phải phản ánh mô hình miền của bạn; nếu bạn thực sự có 70 (100, bạn có gì) thuộc cùng một thực thể thì không có lý do gì để tách chúng thành nhiều bảng.

— ChssPly76
nguồn

29

@KM - đó là lý do tại sao tôi nói "các thuộc tính thuộc cùng một thực thể trên mô hình miền". Số cột cao trong bảng KHÔNG làm cho nó không chuẩn hóa; đó là những gì đã nói các cột đại diện cho điều đó. Bên cạnh đó, mặc dù bình thường hóa chắc chắn là một điều tốt nhưng nó KHÔNG PHẢI là giải pháp cho mọi vấn đề của cuộc sống. Câu hỏi mẹo - bạn có nghĩ rằng số phiếu bầu bên cạnh câu hỏi / câu trả lời SO được tính như select count(*) from votesmọi lần hay bạn nghĩ rằng có lẽ nó đã được chuẩn hóa? Điều đó có làm cho cơ sở dữ liệu SO trở nên tồi tệ và Jeff Atwood trở nên điên rồ?

— ChssPly76 25/09/09

@ ChssPly76, nó là một cơ sở dữ liệu quan hệ không phải là một mô hình đối tượng. có các bảng, hàng và cột, làm việc trong giới hạn đó nếu bạn muốn hiệu suất tối đa, bắt chước các đối tượng của bạn để thuận tiện cho hiệu suất. Vì vậy, mọi thông tin về một người có nên được lưu trữ trong cùng một hàng không? không, hãy chia nhỏ chúng ra và nhóm chúng thành các bảng khác nhau (sử dụng ví dụ mẫu nhận xét trước đây của tôi): "Người", "Hoạt động" "HealthRecords". Lưu trữ một SUM vì lý do hiệu suất là một vấn đề hoàn toàn khác so với việc giữ tất cả dữ liệu trong 70 cột để tránh kết hợp.

— KM.

20

"NumberOfTeethPulled" có nên là một phần của bản ghi Người không? Không, nó có thể hoàn toàn không được lưu trữ - bạn sẽ nhận được thông tin đó từ "ToothExtractionRecord" nếu mô hình miền của bạn yêu cầu mức độ chi tiết như vậy. Nhưng đó là ví dụ của BẠN (và, tôi dám nói, đúng hơn là giả thiết) - nó không liên quan gì đến quan điểm của tôi: số lượng lớn các cột trong một bảng KHÔNG có nghĩa là bảng không chuẩn hóa. Hãy nghĩ đến các hợp đồng bất động sản / đơn đặt hàng / tài liệu tài chính khác chỉ để nêu tên một vài ví dụ. Chúng có thể được chia thành nhiều bảng không? Đúng. Bất kỳ lý do để làm như vậy? Không hẳn.

— ChssPly76

1

+1, điều đó thật vui nhộn. Nếu bạn đang tạo một bảng khác và nó chỉ là mối quan hệ 1: 1, bạn có thể chỉ nên đưa nó vào bảng chính. Nó sẽ không tiết kiệm dung lượng, Nó sẽ không hoạt động tốt hơn nhiều nếu bạn không yêu cầu dữ liệu và nó không có trong bảng. Lý do duy nhất hợp pháp mà nói đến cái tâm đối với tôi ngay bây giờ, là nếu có thông tin nhạy cảm trong đó như SSN, tín dụng thông tin thẻ, vv ...

— Vandel212

1

Nếu tôi có một bảng có 15 cols và một bảng khác có 300 cols, khóa chính của hai bảng giống nhau. Chọn một cột trong hai bảng, hiệu suất có khác nhau đáng kể không?

— một đề nghị không thể từ chối

28

Có một số lợi ích khi chia bảng thành nhiều bảng với ít cột hơn, còn được gọi là Phân vùng theo chiều dọc . Ở đây có một ít:

Nếu bạn có các bảng có nhiều hàng, việc sửa đổi các chỉ mục có thể mất nhiều thời gian, vì MySQL cần xây dựng lại tất cả các chỉ mục trong bảng. Việc tách các chỉ mục thành một số bảng có thể làm cho việc đó nhanh hơn.
Tùy thuộc vào các truy vấn và kiểu cột của bạn, MySQL có thể ghi các bảng tạm thời (được sử dụng trong các truy vấn chọn phức tạp hơn) vào đĩa. Điều này thật tệ, vì đĩa i / o có thể là một cái cổ chai lớn. Điều này xảy ra nếu bạn có dữ liệu nhị phân (văn bản hoặc đốm màu) trong truy vấn.
Bảng rộng hơn có thể dẫn đến hiệu suất truy vấn chậm hơn.

Đừng tối ưu hóa quá sớm, nhưng trong một số trường hợp, bạn có thể nhận được những cải tiến từ các bảng hẹp hơn.

— jonstjohn
nguồn

5

Tại sao MySQL cần xây dựng lại tất cả các chỉ mục trong bảng nếu chỉ có một chỉ mục được sửa đổi?

— Petr Peller

Tôi cũng tự hỏi như vậy. Tại sao MySQL xây dựng lại tất cả các chỉ mục trong bảng? Nhận định trên có đúng không?

— maj

13

Nó là quá nhiều khi nó vi phạm các quy tắc bình thường hóa. Rất khó để có được nhiều cột đó nếu bạn đang chuẩn hóa cơ sở dữ liệu của mình. Thiết kế cơ sở dữ liệu của bạn để mô hình hóa vấn đề, không xoay quanh bất kỳ quy tắc hoặc ý tưởng nhân tạo nào về việc tối ưu hóa cho một nền tảng db cụ thể.

Áp dụng các quy tắc sau cho bảng rộng và bạn có thể sẽ có ít cột hơn nhiều trong một bảng.

Không có phần tử hoặc nhóm phần tử lặp lại
Không có phụ thuộc từng phần vào một khóa được nối
Không phụ thuộc vào các thuộc tính không phải khóa

Đây là một liên kết để giúp bạn cùng.

— JohnFx
nguồn

17

It is pretty hard to get that many columns if you are normalizing your database.Không khó như nó có vẻ.

— Petr Peller

5

Chắc chắn là không khó. Mọi người dường như không thực sự hiểu các hình thức bình thường xung quanh các bộ phận này. Bạn có thể có 10000 cột và VẪN được chuẩn hóa (ngay cả ở dạng bình thường cao nhất).

— Hejazzman

2

@foljs Và đó chính xác là lúc thực hành được chấp nhận về tiêu chuẩn hóa xuất hiện. Nếu bạn đang ở giao lộ và một chiếc ô tô chuẩn bị lao vào bạn, sẽ thật ngu ngốc khi đợi đèn chuyển sang màu xanh. Bạn phải tránh ra khỏi con đường. Trong khi đi qua đèn đỏ có thể không về mặt kỹ thuật được quy phạm pháp luật, bạn đang làm gì bạn nên rõ ràng làm cho tình hình = denormalization

— user3308043

3

Bạn đã đánh mất tôi khi bạn bắt đầu nói về xe hơi. Không biết mức độ liên quan là gì.

— JohnFx

2

Tuy nhiên, làm thế nào để bạn thực hiện các truy vấn phức tạp trong trường hợp này với một bảng dữ liệu, bạn không thể, bạn phải phụ thuộc rất nhiều vào ngôn ngữ lập trình và nhiều thứ khác để làm cho nó hoạt động! Vì vậy, tôi cũng có thể quay lại việc có một bảng với 170 cột, bởi vì việc có các truy vấn "THAM GIA" và lập trình phức tạp hơn yêu cầu làm cho các bảng riêng biệt hoạt động với tôi dường như là một sự lãng phí thời gian. Tôi đoán tôi là một fan hâm mộ lớn của nguyên tắc KISS.

— Vlad Vladimir Hercules

0

Đó không phải là vấn đề trừ khi tất cả các thuộc tính thuộc cùng một thực thể và không phụ thuộc vào nhau. Để làm cho cuộc sống dễ dàng hơn, bạn có thể có một cột văn bản với mảng JSON được lưu trữ trong đó. Rõ ràng, nếu bạn không gặp vấn đề với việc nhận tất cả các thuộc tính mọi lúc. Mặc dù điều này sẽ hoàn toàn đánh bại mục đích lưu trữ nó trong RDBMS và sẽ làm phức tạp mọi giao dịch cơ sở dữ liệu. Vì vậy, cách tiếp cận không được khuyến nghị của nó được tuân theo trong toàn bộ cơ sở dữ liệu.

— Zeeshan Ch
nguồn

0

Có quá nhiều cột trong cùng một bảng cũng có thể gây ra vấn đề lớn trong việc sao chép. Bạn nên biết rằng những thay đổi xảy ra trong cái chính sẽ sao chép sang cái phụ .. ví dụ: nếu bạn cập nhật một trường trong bảng, toàn bộ hàng sẽ là w

— Hôm nay
nguồn