Сіз «Әдемі бағандар» антипаттернімен кездестіңіз бе…

Иә, кездестім. "Көркем бағандар" (Stripey Data, Rainbow Data) — деректерді сақтау антипаттерні, онда әртүрлі деректер түрлері, логикалық байланысты, бір кестедегі көптеген бағандарға шашыраңқы орналасады, нормализацияны қолданбай, байланысты объектілерге бөлінбейді.

Мысал: пайдаланушылар кестесі, онда туған күн, мекенжай, телефон, электронды пошта, тіркелу күні, соңғы кіріс, статус (мысалы, активті, блокталған), пайдаланушы түрі (әкімші, қалыпты, қонақ), сондай-ақ бағандар баптауларды, қалауларды, байланысты ID-лерді сақтау үшін.

Мен байқалған мәселелер:

Сұраулардың күрделілігі: нақты ақпарат алу үшін кең кестеден таңдау қажет, көбінесе бұл бағандар үшін NULL мәндері бар, олар қолданылмайды. SELECT мекенжай, қала FROM пайдаланушылар WHERE статус = 'активті' ЖӘНЕ пайдаланушы_түрі = 'қалыпты'.
Қайталау: тек белгілі бір пайдаланушы түрі немесе статусы үшін маңызды өрістер барлық жазбаларда орын алады.
Құрылымды өзгерту қиыншылығы: жаңа деректер түрлерін немесе сипаттамаларын қосу күрделі, себебі барлық кестеге жаңа бағандар қосу керек.
Өнімділік: кең кестелер сұраулардың өнімділігіне әсер етуі мүмкін, әсіресе UPDATE және INSERT кезінде, себебі көп бағандарды өңдеу қажет.
Реляциялық дерекқор принциптерін бұзу: нормализация еленбейді, бұл аномалияларға әкеледі (қосу, жою, жаңарту).
Құрылымды түсінудің қиындығы: әзірлеушілер әр бағанның мақсатын және басқа деректермен байланысын түсінуде қиындықтарға тап болады.

Менің тәжірибем мұндай құрылымдарды қайта құруға негізделген. Біз негізгі кестені бірнеше байланысты кестеге бөлдік:

пайдаланушылар (негізгі деректер: ID, аты, тіркелу күні)
пайдаланушы_профилдері (байланыс деректері: мекенжай, телефон, электронды пошта, ID арқылы пайдаланушыларға)
пайдаланушы_бағдарламалары (интерфейс баптаулары, хабарламалар, ID арқылы пайдаланушыларға)
пайдаланушы_түрлері (түрдің ID-і, атауы, сипаттамасы)

Сыртқы кілттерді пайдаланып байланыстырдық. Бұл кестелер санын арттырса да, сұрауларды әлдеқайда жеңілдетті, икемділікті арттырды және деректер құрылымын түсінуді жақсартты.

-- Мысал, рефакторинг алдында:
CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    name TEXT,
    email TEXT,
    address TEXT,          -- NULL болуы мүмкін
    phone TEXT,            -- NULL болуы мүмкін
    registration_date TEXT,
    last_login TEXT,
    status TEXT,           -- 'активті', 'блокталған', 'күту' 
    user_type TEXT,        -- 'әкімші', 'қалыпты', 'қонақ'
    admin_approval_date TEXT -- тек әкімшілер үшін маңызды? NULL болуы мүмкін
);

-- Мысал, рефакторингтен кейін:
CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    name TEXT,
    registration_date TEXT,
    last_login TEXT,
    user_status TEXT, -- статустар кестесімен байланыс, егер күрделі болса
    user_type_id INTEGER,
    FOREIGN KEY(user_type_id) REFERENCES user_types(id)
);

CREATE TABLE user_details (
    user_id INTEGER PRIMARY KEY,
    email TEXT,
    address TEXT,
    phone TEXT,
    FOREIGN KEY(user_id) REFERENCES users(id)
);

CREATE TABLE user_types (
    id INTEGER PRIMARY KEY,
    type_name TEXT UNIQUE
);

Нәтижесінде, деректерді көшіру үшін үлкен күш жұмсалғанымен, жаңа құрылым масштабталатын, түсінуге оңай әрі қолдауға ыңғайлы болды.

Сіз «Әдемі бағандар» антипаттернімен кездестіңіз бе? Онымен жұмыс істеу тәжірибеңіз туралы айта аласыз ба?