Đồng nghiệp của tôi đã tạo một bảng SQL 96 cột

Chúng tôi ở đây vào năm 2010, các kỹ sư phần mềm có 4 hoặc 5 năm kinh nghiệm, vẫn đang thiết kế các bảng với 96 cột fracking.

Tôi nói với anh ấy rằng đó sẽ là một cơn ác mộng.
Tôi đã cho anh ta thấy rằng chúng ta phải sử dụng các lệnh để giao diện MySQL với C #.
Tôi giải thích rằng các bảng có nhiều cột hơn hàng là một mùi rất lớn.

Tuy nhiên, tôi nhận được "Nó sẽ đơn giản hơn theo cách này".

Tôi nên làm gì?

CHỈNH SỬA *

Bảng này chứa dữ liệu từ các cảm biến.
Chúng tôi có cảm biến 1 với
Dynamic_D1X
Dynamic_D1Y
[...]

Dynamic_D6X
Dynamic_D6Y
[...]

EDIT2 *

Chà, cuối cùng tôi đã rời bỏ công việc đó. Đó là một dấu hiệu khi lập trình viên khác chìm trong nhiều tháng tại thời điểm đó, đó là một dấu hiệu khác khi quản lý không nhận ra đây là một vấn đề

Có lẽ anh ấy đã làm điều đó vì một lý do tốt, chẳng hạn như màn trình diễn hoặc ROI? .

Điều tốt nhất để làm, là hỏi anh ta câu hỏi. Với một lượng "tại sao" nhất định, bạn chắc chắn sẽ khiến anh ấy hiểu rằng anh ấy có thể tự sai (nếu anh ấy thực sự).

Bản thân tôi đã có một trường hợp không liên quan đến biểu diễn nhưng lợi tức đầu tư (ROI). Tôi đã có một bảng chứa các đối tượng có giá trị cụ thể cho mỗi giờ trong tuần (168h trong một tuần). Chúng tôi có lựa chọn tạo một bảng ObjectHour có chứa giá trị, nhưng cũng là một khóa cho Đối tượng và số ngày của số giờ. Nhưng chúng tôi cũng đã có cơ hội để đặt 168 giá trị ngay trong hàng. Có lẽ giống như những gì đồng nghiệp của bạn đã làm.

Các nhà phát triển ước tính cả hai giải pháp. Giải pháp đơn giản (168 cột) rẻ hơn rất nhiều so với đối tác được thiết kế tốt. Đối với kết quả chính xác cho khách hàng.

Chúng tôi quyết định tìm giải pháp đơn giản / rẻ nhất để tập trung nỗ lực vào những thứ quan trọng hơn như bảo mật.

Chúng tôi sẽ có nhiều cơ hội để cải thiện điều đó trong tương lai. Thời gian để thị trường là ưu tiên cho chúng tôi tại thời điểm đó.

Thật không may, nhà phát triển trung bình của bạn vẫn nghĩ về cơ sở dữ liệu quan hệ như các tệp phẳng lớn. Cách duy nhất họ sẽ trở nên tốt hơn là nếu ai đó chịu trách nhiệm và dẫn dắt bằng ví dụ. Gần đây tôi đã đi đầu trong một thiết kế lại chính của một lược đồ quan trọng trong cơ sở dữ liệu của chúng tôi và tuân theo các thực tiễn quan hệ phổ biến. Tất cả các thủ tục lưu trữ của chúng tôi đột nhiên thanh lịch hơn và tất cả các chỉ mục thích hợp dường như rơi vào vị trí giống như chúng được sinh ra cho nó. Nhà phát triển hướng bản ngã sẽ không bao giờ tin bạn nếu không có bằng chứng.

Một cái gì đó tương tự đã được thảo luận trước đây trên StackOverflow .

Nói chung, có nhiều cột trên bàn không nhất thiết có nghĩa là bạn đang làm gì đó sai, nhưng chắc chắn nên treo một số cờ đỏ để bạn nhìn kỹ vào thiết kế. Đôi khi một chiếc bàn khổng lồ là lựa chọn đúng đắn, nhưng trong nhiều trường hợp, các lựa chọn thay thế khác có ý nghĩa hơn. Ví dụ: một tùy chọn là chia lưu trữ thành hai bảng: một bảng xác định các thực thể của bạn và một bảng khác thực sự là kho lưu trữ khóa / giá trị của các thuộc tính mô tả các thực thể đó (vì vậy bạn có thể kết thúc với tối đa 96 hàngcho mỗi thực thể). Thiết kế khác là có thể là tốt. Nói chuyện với các đồng đội của bạn và tìm ra giải pháp nào tốt hơn tùy thuộc vào chuẩn hóa dữ liệu, khả năng đọc và bảo trì mã (chèn câu lệnh với 96 thuộc tính để điền vào?), Hàm ý hiệu suất, tần suất các thuộc tính mới (cột) có thể được thêm hoặc thay đổi, mức độ thưa thớt dữ liệu là (bao nhiêu trong số 96 cột sẽ được điền và bao nhiêu NULL vẫn còn?), và ý nghĩa về báo cáo. Bất kỳ nhà phát triển nào cũng có thể biện minh hợp lý cho các quyết định thiết kế của họ và cho thấy rằng sự đánh đổi chi phí / lợi ích (và vâng, mọi quyết định thiết kế là một sự đánh đổi) đều có lợi cho họ. Trách nhiệm của bạn không phải là phàn nàn hay chỉ trích, mà là đề xuất các giải pháp thay thế và đảm bảo rằng họ đã nghĩ thông qua những vấn đề này.

Được chuẩn hóa với 96 cột? Nó có đáp ứng NF 1, 2, 3 vv không?

Có thể là bạn có 96 thuộc tính riêng biệt cho thực thể.

Nếu không, hãy khiến anh ấy đọc Joe Celko trên Simple Talk

Nó hoàn toàn phụ thuộc.

Các thiết kế DB được chuẩn hóa / không chuẩn hóa đều có những ưu điểm và nhược điểm.

Thiết kế DB đầu tiên của tôi là một thứ bình thường của cái đẹp. Nó rất linh hoạt và có thể mở rộng. Nó cũng là một PITA đáng kinh ngạc cho bất cứ ai ngoại trừ bản thân tôi để giải quyết ở cấp độ mã, và đó là một PITA nhẹ đối với tôi.

Nỗ lực tiếp theo của tôi là một cấu trúc phẳng, và nó (a) nhanh hơn rất nhiều và (b) dễ mã hóa hơn rất nhiều. Và nó sẽ không phải là một việc lớn để bình thường hóa sau này.

Vì vậy, nó có thể là một mùi nhưng một số thiết kế DB khác sẽ có một mùi thú vị riêng của nó.

Để anh ta đọc bài viết này về nợ kỹ thuật . Nếu anh ấy vẫn quyết định giữ nó theo cách này, thì ít nhất bạn đã đưa ra một ý kiến ​​mang tính xây dựng.

Nhìn vào bài đăng (đã chỉnh sửa), rõ ràng đây là một bảng không chuẩn hóa. Những gì bạn nên làm? Như tôi thấy, bạn có một vài lựa chọn:

1. Hét vào đồng nghiệp của bạn để học cách làm công việc của anh ấy / cô ấy. Không có khả năng làm việc hiệu quả nhưng có thể sẽ thuyết phục các đồng nghiệp khác không gây rối với bạn. Danh tiếng như một kẻ điên hét lên có thể hữu ích (đừng hỏi tôi làm sao tôi biết).
2. Hét lên với ông chủ rằng đồng nghiệp là một thằng ngốc. Dự báo thảm họa, sau đó tích cực làm việc để phá hoại dự án. Đổ lỗi cho tất cả mọi thứ trên thiết kế cơ sở dữ liệu được sản xuất bởi đồng nghiệp bất tài. Có thể dẫn trực tiếp đến ...
3. Thoát Tốt nhất nếu đó là ý tưởng của bạn, nhưng # 2 có thể dẫn đến sự từ chức không tự nguyện. Cố gắng không cạo đầu gối trên nhựa đường / bê tông / sỏi nếu bị ném từ cửa sổ bởi ông chủ và / hoặc đồng nghiệp giận dữ. (Lưu ý rằng nghiên cứu trước là QUAN TRỌNG ở đây. Cơ hội sống sót của bạn giảm rõ rệt nếu văn phòng ông chủ ở trên tầng trệt và bạn thấy mình bị đẩy ra ngoài cửa sổ. Hãy lên kế hoạch trước !! )
4. Uống nhiều - hoặc, di chuyển đến California và sáng lên (giả sử prop 19 (hoặc bất cứ điều gì) đi qua). Không có gì giống như một vài bức ảnh và một doobie để cải thiện tầm nhìn của một người đối với đồng nghiệp của mình (hoặc vì vậy tôi đã nghe thấy). (Thông báo dịch vụ công cộng: KIDS! Những người này là chuyên gia! KHÔNG thử điều này ở nhà!)

Chia sẻ và tận hưởng.

Tôi sẽ đi ra ngoài một chi ở đây và cho rằng anh ta sẽ cắt và dán rất nhiều mã để làm việc với bảng "Mới" này.

Nếu vậy, bạn có thể sẽ không phải chịu thêm bất kỳ khoản nợ kỹ thuật nào. Anh ta chỉ chia phần nợ kỹ thuật của mình và có thể đang trên đường đến một sự thống nhất lớn nào đó của mọi thứ.

Nếu anh ta có một số phương pháp thử và thực sự đòi hỏi một điều 96 cột, hãy xem xét lợi ích thực tế của việc thực hiện nó theo một cách khác trong trường hợp cụ thể này. Nếu không có ai, thì hãy cho anh ta lợi ích của sự nghi ngờ, nhưng hãy nhắc anh ta rằng lần sau bạn muốn tham gia vào giai đoạn lập kế hoạch vào lần tới, anh ta sẽ làm những gì chúng ta coi là một bước đi khá ngu ngốc.

Phụ thuộc hoàn toàn vào các trường hợp sử dụng của ứng dụng sẽ truy cập vào lược đồ, khối dữ liệu nào là cần thiết tại một thời điểm. Theo một cách nào đó, nó có thể biện minh cho thiết kế bảng.

Tôi sẽ gửi anh ta đến thời kỳ đồ đá và buộc anh ta sử dụng các tập tin hoặc ít nhất là dạy anh ta cách sử dụng các đốm màu.

Thực sự, 96 màu ... Điều đó không thể đúng, bao giờ. Có lẽ một ORM sẽ giúp. (Trừ khi bạn cần hiệu suất nhưng sau đó bạn có thể có người hiểu DB tốt hơn để xử lý nó)

Tôi sẽ bị hạ bệ tất cả xuống địa ngục vì điều này, nhưng đây chính là lý do tại sao tôi tách biệt trách nhiệm của mô hình hóa dữ liệu và công nghệ phần mềm trong cửa hàng của mình. Các lập trình viên dường như hiếm khi nghĩ về các hình thức tập hợp và thay vào đó tập trung vào việc sử dụng dữ liệu (thay vì duy trì hình thức bình thường thứ 3, lập chỉ mục hoặc các vấn đề về hiệu suất DB khác). Chúng tôi với tư cách là lập trình viên cũng có xu hướng không đồng ý nhiều hơn với các quyết định kiến ​​trúc DB đó hơn là có thể, dựa trên sự thiếu kinh nghiệm của chúng tôi trong các vấn đề mô hình hóa / kiến ​​trúc dữ liệu thuần túy. IMHO, tôi thích rằng tôi có các kiến ​​trúc sư dữ liệu và người lập mô hình đưa ra các yêu cầu, xây dựng bảng / procs / v.v., và để lại việc xử lý các kết quả đầu ra cho tôi.

Mặc dù không biết lý do thực sự của thiết kế này (Tôi đã làm việc trên các cảm biến thời tiết có hơn 96 đầu ra số khác nhau = số lượng lớn các cột của bảng) ... điều này có vẻ giống như trút hơi vào vật nuôi.