Các mô hình chống SQL phổ biến nhất là gì? [đóng cửa]

Tất cả chúng ta làm việc với các cơ sở dữ liệu quan hệ đã học (hoặc đang học) rằng SQL là khác nhau. Lấy kết quả mong muốn và thực hiện một cách hiệu quả, bao gồm một quá trình tẻ nhạt một phần được đặc trưng bằng cách học các mô hình lạ, và phát hiện ra rằng một số mô hình lập trình quen thuộc nhất của chúng ta không hoạt động ở đây. Các antipotype phổ biến bạn đã thấy (hoặc bản thân bạn đã cam kết) là gì?

Tôi luôn cảm thấy thất vọng bởi hầu hết các lập trình viên có xu hướng trộn logic UI của họ vào lớp truy cập dữ liệu:

SELECT
    FirstName + ' ' + LastName as "Full Name",
    case UserRole
        when 2 then "Admin"
        when 1 then "Moderator"
        else "User"
    end as "User's Role",
    case SignedIn
        when 0 then "Logged in"
        else "Logged out"
    end as "User signed in?",
    Convert(varchar(100), LastSignOn, 101) as "Last Sign On",
    DateDiff('d', LastSignOn, getDate()) as "Days since last sign on",
    AddrLine1 + ' ' + AddrLine2 + ' ' + AddrLine3 + ' ' +
        City + ', ' + State + ' ' + Zip as "Address",
    'XXX-XX-' + Substring(
        Convert(varchar(9), SSN), 6, 4) as "Social Security #"
FROM Users

Thông thường, các lập trình viên làm điều này bởi vì họ có ý định liên kết trực tiếp tập dữ liệu của họ vào lưới và thật tiện lợi khi có máy chủ định dạng SQL Server phía máy chủ hơn định dạng trên máy khách.

Các truy vấn như cái được hiển thị ở trên cực kỳ dễ vỡ vì chúng kết hợp chặt chẽ lớp dữ liệu với lớp UI. Trên hết, phong cách lập trình này ngăn chặn triệt để các thủ tục được lưu trữ không thể tái sử dụng.

Dưới đây là top 3 của tôi.

Số 1. Không chỉ định danh sách trường. (Chỉnh sửa: để tránh nhầm lẫn: đây là quy tắc mã sản xuất. Nó không áp dụng cho các tập lệnh phân tích một lần - trừ khi tôi là tác giả.)

SELECT *
Insert Into blah SELECT *

nên là

SELECT fieldlist
Insert Into blah (fieldlist) SELECT fieldlist

Số 2. Sử dụng một con trỏ và vòng lặp while, khi một vòng lặp while có biến vòng lặp sẽ làm.

DECLARE @LoopVar int

SET @LoopVar = (SELECT MIN(TheKey) FROM TheTable)
WHILE @LoopVar is not null
BEGIN
  -- Do Stuff with current value of @LoopVar
  ...
  --Ok, done, now get the next value
  SET @LoopVar = (SELECT MIN(TheKey) FROM TheTable
    WHERE @LoopVar < TheKey)
END

Số 3. DateLogic thông qua các loại chuỗi.

--Trim the time
Convert(Convert(theDate, varchar(10), 121), datetime)

Nên là

--Trim the time
DateAdd(dd, DateDiff(dd, 0, theDate), 0)

Tôi đã thấy một đột biến gần đây của "Một truy vấn tốt hơn hai, đáng kinh ngạc?"

SELECT *
FROM blah
WHERE (blah.Name = @name OR @name is null)
  AND (blah.Purpose = @Purpose OR @Purpose is null)

Truy vấn này yêu cầu hai hoặc ba kế hoạch thực hiện khác nhau tùy thuộc vào các giá trị của các tham số. Chỉ có một kế hoạch thực hiện được tạo và mắc kẹt vào bộ đệm cho văn bản sql này. Kế hoạch đó sẽ được sử dụng bất kể giá trị của các tham số. Điều này dẫn đến hiệu suất kém liên tục. Sẽ tốt hơn nhiều khi viết hai truy vấn (một truy vấn cho mỗi kế hoạch thực hiện dự định).

• Các trường mật khẩu có thể đọc được của con người , egad. Tự giải thích.

• Sử dụng THÍCH đối với các cột được lập chỉ mục và tôi gần như muốn nói chung là THÍCH.

• Tái chế các giá trị PK do SQL tạo.

• Bất ngờ không ai nhắc đến bàn thần . Không có gì nói "hữu cơ" như 100 cột cờ bit, chuỗi lớn và số nguyên.

• Sau đó, có mẫu "Tôi nhớ tệp .ini" : lưu trữ CSV, chuỗi được phân tách bằng đường ống hoặc dữ liệu cần thiết khác trong các trường văn bản lớn.

• Và đối với máy chủ MS SQL, việc sử dụng các con trỏ hoàn toàn . Có một cách tốt hơn để thực hiện bất kỳ tác vụ con trỏ nhất định.

Đã chỉnh sửa vì có rất nhiều!

Đừng đào sâu cho nó: Không sử dụng các tuyên bố đã chuẩn bị.

Sử dụng bí danh bảng vô nghĩa:

from employee t1,
department t2,
job t3,
...

Làm cho việc đọc một câu lệnh SQL lớn trở nên khó hơn nhiều so với yêu cầu

var query = "select COUNT(*) from Users where UserName = '" 
            + tbUser.Text 
            + "' and Password = '" 
            + tbPassword.Text +"'";

1. Người dùng tin tưởng mù quáng
2. Không sử dụng truy vấn tham số
3. Mật khẩu Cleartext

Lỗi của tôi là các bảng Truy cập 450 cột được đặt bởi con trai 8 tuổi của người chăm sóc chó bạn thân của Giám đốc điều hành và bảng tra cứu tinh ranh chỉ tồn tại vì ai đó không biết cách bình thường hóa cơ sở hạ tầng đúng cách.

Thông thường, bảng tra cứu này trông như thế này:

ID INT,
Tên NVARCHAR (132),
IntValue1 INT,
IntValue2 INT,
CharValue1 NVARCHAR (255),
CharValue2 NVARCHAR (255),
NGÀY 1 NGÀY,
Ngày 2 NGÀY

Tôi đã mất số lượng khách hàng tôi đã thấy những người có hệ thống dựa trên sự ghê tởm như thế này.

Những cái mà tôi không thích nhất là

1. Sử dụng khoảng trắng khi tạo bảng, sprocs, v.v. Tôi đã gặp phải điều này) thực sự làm tôi khó chịu.

2. Dữ liệu không chuẩn hóa. Một bảng không cần phải được chuẩn hóa hoàn toàn, nhưng khi tôi gặp một bảng nhân viên có thông tin về điểm đánh giá hiện tại hoặc bất cứ điều gì chính của họ, điều đó cho tôi biết rằng có lẽ tôi sẽ cần phải tạo một bảng riêng biệt vào một lúc nào đó và sau đó cố gắng giữ chúng được đồng bộ hóa. Tôi sẽ bình thường hóa dữ liệu trước và sau đó nếu tôi thấy một nơi giúp chuẩn hóa, tôi sẽ xem xét nó.

3. Sử dụng quá mức các quan điểm hoặc con trỏ. Lượt xem có một mục đích, nhưng khi mỗi bảng được bao bọc trong một khung nhìn thì nó quá nhiều. Tôi đã phải sử dụng con trỏ một vài lần, nhưng nhìn chung bạn có thể sử dụng các cơ chế khác cho việc này.

4. Truy cập. Một chương trình có thể là một mô hình chống? Chúng tôi có SQL Server trong công việc của tôi, nhưng một số người sử dụng quyền truy cập do tính khả dụng, "dễ sử dụng" và "thân thiện" với người dùng không có kỹ thuật. Có quá nhiều thứ ở đây để đi vào, nhưng nếu bạn đã ở trong một môi trường tương tự, bạn biết đấy.

sử dụng SP làm tiền tố của tên thủ tục lưu trữ vì trước tiên nó sẽ tìm kiếm trong vị trí thủ tục hệ thống thay vì vị trí thủ tục tùy chỉnh.

Sử dụng quá mức các bảng tạm thời và con trỏ.

Để lưu trữ giá trị thời gian, chỉ nên sử dụng múi giờ UTC. Giờ địa phương không nên được sử dụng.

sử dụng @@ IDENTITY thay vì SCOPE_IDENTITY ()

Trích dẫn từ câu trả lời này :

• @@ IDENTITY trả về giá trị nhận dạng cuối cùng được tạo cho bất kỳ bảng nào trong phiên hiện tại, trên tất cả các phạm vi. Bạn cần phải cẩn thận ở đây, vì nó trên phạm vi. Bạn có thể nhận được một giá trị từ một kích hoạt, thay vì tuyên bố hiện tại của bạn.
• SCOPE_IDENTITY trả về giá trị nhận dạng cuối cùng được tạo cho bất kỳ bảng nào trong phiên hiện tại và phạm vi hiện tại. Nói chung những gì bạn muốn sử dụng.
• IDENT_CURRENT trả về giá trị nhận dạng cuối cùng được tạo cho một bảng cụ thể trong bất kỳ phiên nào và bất kỳ phạm vi nào. Điều này cho phép bạn chỉ định bảng nào bạn muốn giá trị từ đó, trong trường hợp hai bảng trên không hoàn toàn là thứ bạn cần (rất hiếm). Bạn có thể sử dụng điều này nếu bạn muốn nhận giá trị IDENTITY hiện tại cho một bảng mà bạn chưa chèn bản ghi vào.

Sử dụng lại trường 'chết' cho mục đích mà nó không dành cho (ví dụ: lưu trữ dữ liệu người dùng trong trường 'Fax') - rất hấp dẫn như một cách khắc phục nhanh chóng!

select some_column, ...
from some_table
group by some_column

và giả sử rằng kết quả sẽ được sắp xếp theo some_column. Tôi đã thấy điều này một chút với Sybase nơi giả định được giữ (hiện tại).

SELECT FirstName + ' ' + LastName as "Full Name", case UserRole when 2 then "Admin" when 1 then "Moderator" else "User" end as "User's Role", case SignedIn when 0 then "Logged in" else "Logged out" end as "User signed in?", Convert(varchar(100), LastSignOn, 101) as "Last Sign On", DateDiff('d', LastSignOn, getDate()) as "Days since last sign on", AddrLine1 + ' ' + AddrLine2 + ' ' + AddrLine3 + ' ' + City + ', ' + State + ' ' + Zip as "Address", 'XXX-XX-' + Substring(Convert(varchar(9), SSN), 6, 4) as "Social Security #" FROM Users

Hoặc, nhồi nhét mọi thứ vào một dòng.

• Các FROM TableA, TableB WHEREcú pháp cho NỐI hơnFROM TableA INNER JOIN TableB ON

• Giả định rằng một truy vấn sẽ được trả về đã sắp xếp một cách nhất định mà không đặt mệnh đề ORDER BY vào, chỉ vì đó là cách nó xuất hiện trong quá trình thử nghiệm trong công cụ truy vấn.

Học SQL trong sáu tháng đầu tiên của sự nghiệp và không bao giờ học bất cứ điều gì khác trong 10 năm tiếp theo. Đặc biệt là không học hoặc sử dụng hiệu quả các tính năng SQL phân tích / cửa sổ. Cụ thể là việc sử dụng over () và phân vùng bởi.

Các hàm cửa sổ, giống như các hàm tổng hợp, thực hiện tổng hợp trên một tập hợp xác định (một nhóm) các hàng, nhưng thay vì trả về một giá trị cho mỗi nhóm, các hàm cửa sổ có thể trả về nhiều giá trị cho mỗi nhóm.

Xem O'Reilly SQL Cookbook Phụ lục A để biết tổng quan đẹp về các chức năng cửa sổ.

Tôi cần đặt yêu thích hiện tại của riêng tôi ở đây, chỉ để làm cho danh sách đầy đủ. Antipotype yêu thích của tôi không kiểm tra truy vấn của bạn .

Điều này áp dụng khi:

1. Truy vấn của bạn liên quan đến nhiều hơn một bảng.
2. Bạn nghĩ rằng bạn có một thiết kế tối ưu cho một truy vấn, nhưng đừng bận tâm kiểm tra các giả định của bạn.
3. Bạn chấp nhận truy vấn đầu tiên hoạt động, không có manh mối nào về việc nó thậm chí gần với tối ưu hóa hay không.

Và bất kỳ thử nghiệm nào chạy với dữ liệu không điển hình hoặc không đủ đều không được tính. Nếu đó là một thủ tục được lưu trữ, hãy đặt câu lệnh kiểm tra vào một bình luận và lưu nó, với kết quả. Nếu không, đặt nó vào một nhận xét trong mã với kết quả.

Lạm dụng bảng tạm thời.

Cụ thể là loại điều này:

SELECT personid, firstname, lastname, age
INTO #tmpPeople
FROM People
WHERE lastname like 's%'

DELETE FROM #tmpPeople
WHERE firstname = 'John'

DELETE FROM #tmpPeople
WHERE firstname = 'Jon'

DELETE FROM #tmpPeople
WHERE age > 35

UPDATE People
SET firstname = 'Fred'
WHERE personid IN (SELECT personid from #tmpPeople)

Không xây dựng bảng tạm thời từ một truy vấn, chỉ để xóa các hàng bạn không cần.

Và vâng, tôi đã thấy các trang mã ở dạng này trong các DB sản xuất.

Quan điểm trái ngược: quá ám ảnh với bình thường hóa.

Hầu hết các hệ thống SQL / RBDB cung cấp một tính năng (giao dịch, sao chép) khá hữu ích, ngay cả với dữ liệu không chuẩn hóa. Dung lượng ổ đĩa rẻ và đôi khi có thể đơn giản hơn (mã dễ dàng hơn, thời gian phát triển nhanh hơn) để thao tác / lọc / tìm kiếm dữ liệu được tìm nạp, hơn là viết lên lược đồ 1NF và xử lý tất cả các rắc rối trong đó (tham gia phức tạp, chọn lọc khó chịu , Vân vân).

Tôi đã tìm thấy các hệ thống quá mức bình thường hóa thường được tối ưu hóa sớm, đặc biệt là trong giai đoạn phát triển ban đầu.

(suy nghĩ nhiều hơn về nó ... http://writeonly.wordpress.com/2008/12/05/simple-object-db-USE-json-and-python-sqlite/ )

Tôi chỉ kết hợp cái này với nhau, dựa trên một số câu trả lời SQL ở đây trên SO.

Đây là một phản đề nghiêm trọng khi nghĩ rằng các trình kích hoạt là vào cơ sở dữ liệu vì các trình xử lý sự kiện là OOP. Có nhận thức rằng bất kỳ logic cũ nào cũng có thể được đưa vào kích hoạt, sẽ bị loại bỏ khi một giao dịch (sự kiện) xảy ra trên bàn.

Không đúng. Một trong những khác biệt lớn là các kích hoạt là đồng bộ - với sự báo thù, bởi vì chúng đồng bộ trên một hoạt động được thiết lập, không phải trên một hoạt động hàng. Về phía OOP, hoàn toàn ngược lại - các sự kiện là một cách hiệu quả để thực hiện các giao dịch không đồng bộ.

Các thủ tục hoặc chức năng được lưu trữ mà không có bất kỳ bình luận nào ...

1) Tôi không biết đó là mô hình chống "chính thức", nhưng tôi không thích và cố gắng tránh các chuỗi ký tự như các giá trị ma thuật trong cột cơ sở dữ liệu.

Một ví dụ từ bảng 'hình ảnh' của MediaWiki:

img_media_type ENUM("UNKNOWN", "BITMAP", "DRAWING", "AUDIO", "VIDEO", 
    "MULTIMEDIA", "OFFICE", "TEXT", "EXECUTABLE", "ARCHIVE") default NULL,
img_major_mime ENUM("unknown", "application", "audio", "image", "text", 
    "video", "message", "model", "multipart") NOT NULL default "unknown",

(Tôi chỉ nhận thấy vỏ khác nhau, một điều cần tránh)

Tôi thiết kế các trường hợp như tra cứu int vào các bảng ImageMediaType và ImageMajorMime với các khóa chính.

2) chuyển đổi ngày / chuỗi dựa trên cài đặt NLS cụ thể

CONVERT(NVARCHAR, GETDATE())

không có định dạng

Truy vấn con giống hệt nhau trong một truy vấn.

• Chế độ xem thay đổi - Chế độ xem bị thay đổi quá thường xuyên và không có thông báo hoặc lý do. Sự thay đổi sẽ được chú ý vào thời điểm không phù hợp nhất hoặc tệ hơn là sai và không bao giờ được chú ý. Có thể ứng dụng của bạn sẽ bị hỏng vì ai đó nghĩ ra một cái tên tốt hơn cho cột đó. Theo quan điểm quy tắc nên mở rộng tính hữu dụng của các bảng cơ sở trong khi duy trì hợp đồng với người tiêu dùng. Khắc phục sự cố nhưng không thêm tính năng hoặc thay đổi hành vi tệ hơn, vì điều đó tạo ra một chế độ xem mới. Để giảm thiểu không chia sẻ quan điểm với các dự án khác và, hãy sử dụng CTE khi nền tảng cho phép. Nếu cửa hàng của bạn có DBA, bạn có thể không thể thay đổi lượt xem nhưng tất cả các lượt xem của bạn sẽ bị lỗi thời và hoặc vô dụng trong trường hợp đó.

• The Paramed - Một truy vấn có thể có nhiều mục đích không? Có lẽ nhưng người tiếp theo đọc nó sẽ không biết cho đến khi thiền sâu. Ngay cả khi bạn không cần chúng ngay bây giờ, rất có thể bạn sẽ làm được, ngay cả khi nó "chỉ" để gỡ lỗi. Thêm tham số làm giảm thời gian bảo trì và giữ mọi thứ KHÔ. Nếu bạn có một mệnh đề where, bạn nên có các tham số.

• Trường hợp không có CASE -

  SELECT  
  CASE @problem  
    WHEN 'Need to replace column A with this medium to large collection of strings hanging out in my code.'  
      THEN 'Create a table for lookup and add to your from clause.'  
    WHEN 'Scrubbing values in the result set based on some business rules.'  
      THEN 'Fix the data in the database'  
    WHEN 'Formating dates or numbers.'   
      THEN 'Apply formating in the presentation layer.'  
    WHEN 'Createing a cross tab'  
      THEN 'Good, but in reporting you should probably be using cross tab, matrix or pivot templates'   
  ELSE 'You probably found another case for no CASE but now I have to edit my code instead of enriching the data...' END  

Hai thứ tôi tìm thấy nhiều nhất và có thể có một chi phí đáng kể về mặt hiệu suất là:

• Sử dụng con trỏ thay vì một biểu thức dựa trên tập hợp. Tôi đoán điều này xảy ra thường xuyên khi lập trình viên đang suy nghĩ thủ tục.

• Sử dụng các truy vấn phụ tương quan, khi tham gia vào bảng dẫn xuất có thể thực hiện công việc.

Đưa công cụ vào các bảng tạm thời, đặc biệt là những người chuyển từ SQL Server sang Oracle có thói quen lạm dụng các bảng tạm thời. Chỉ cần sử dụng các câu lệnh chọn lồng nhau.

Các nhà phát triển viết các truy vấn mà không có ý tưởng tốt về những gì làm cho các ứng dụng SQL (cả truy vấn riêng lẻ và hệ thống nhiều người dùng) nhanh hay chậm. Điều này bao gồm sự thiếu hiểu biết về:

• Các chiến lược tối thiểu hóa I / O vật lý, cho rằng nút thắt của hầu hết các truy vấn là I / O không phải CPU
• tác động hoàn hảo của các loại truy cập lưu trữ vật lý khác nhau (ví dụ: nhiều I / O tuần tự sẽ nhanh hơn rất nhiều I / O ngẫu nhiên nhỏ, mặc dù ít hơn nếu bộ lưu trữ vật lý của bạn là SSD!)
• làm cách nào để điều chỉnh truy vấn nếu DBMS tạo ra một kế hoạch truy vấn kém
• cách chẩn đoán hiệu suất cơ sở dữ liệu kém, cách "gỡ lỗi" truy vấn chậm và cách đọc kế hoạch truy vấn (hoặc GIẢI THÍCH, tùy thuộc vào DBMS bạn chọn)
• khóa chiến lược để tối ưu hóa thông lượng và tránh bế tắc trong các ứng dụng đa người dùng
• tầm quan trọng của việc trộn và các thủ thuật khác để xử lý việc xử lý các tập dữ liệu
• thiết kế bảng và chỉ mục để cân bằng tốt nhất không gian và hiệu suất (ví dụ: bao gồm các chỉ mục, giữ các chỉ mục nhỏ nếu có thể, giảm các loại dữ liệu xuống kích thước tối thiểu cần thiết, v.v.)

Sử dụng SQL như một gói ISAM (Phương pháp truy cập tuần tự được lập chỉ mục) được tôn vinh. Cụ thể, các con trỏ lồng nhau thay vì kết hợp các câu lệnh SQL thành một câu lệnh, mặc dù lớn hơn ,. Điều này cũng được tính là "lạm dụng trình tối ưu hóa" vì thực tế không có nhiều trình tối ưu hóa có thể làm. Điều này có thể được kết hợp với các tuyên bố không được chuẩn bị để không hiệu quả tối đa:

DECLARE c1 CURSOR FOR SELECT Col1, Col2, Col3 FROM Table1

FOREACH c1 INTO a.col1, a.col2, a.col3
    DECLARE c2 CURSOR FOR
        SELECT Item1, Item2, Item3
            FROM Table2
            WHERE Table2.Item1 = a.col2
    FOREACH c2 INTO b.item1, b.item2, b.item3
        ...process data from records a and b...
    END FOREACH
END FOREACH

Giải pháp đúng (hầu như luôn luôn) là kết hợp hai câu lệnh CHỌN thành một:

DECLARE c1 CURSOR FOR
    SELECT Col1, Col2, Col3, Item1, Item2, Item3
        FROM Table1, Table2
        WHERE Table2.Item1 = Table1.Col2
        -- ORDER BY Table1.Col1, Table2.Item1

FOREACH c1 INTO a.col1, a.col2, a.col3, b.item1, b.item2, b.item3
    ...process data from records a and b...
END FOREACH

Ưu điểm duy nhất cho phiên bản vòng lặp kép là bạn có thể dễ dàng phát hiện các ngắt giữa các giá trị trong Bảng 1 vì vòng lặp bên trong kết thúc. Đây có thể là một yếu tố trong các báo cáo phá vỡ kiểm soát.

Ngoài ra, sắp xếp trong ứng dụng thường là không.

Sử dụng khóa chính làm đại diện thay thế cho địa chỉ hồ sơ và sử dụng khóa ngoại làm thay thế cho con trỏ được nhúng trong hồ sơ.