- MySQL
- Данни на Guide-Bulgaria.com
- съхранение на данни
- обработка на данни
База данни: MySQL.
Цел: Да се съхранява данни във форма slovarevidnye идентификатор: int-> стойност: низ.
Проблемът: Оказа се, че понякога трябва да съответства на един и същ списък идентификатор стойност. В този случай, дори ако списъкът се състои от един елемент, все пак е необходимо да се разграничи от нормалната стойност.
Виждам няколко решения, но никой не ми харесва.
1) да притежава данните като низ и във всякакъв формат: XML, JSON, и т.н. След това, едно поле низ можете да спестите целия обект.
Опция не харесва факта, че в края на краищата ние се де-нормализиране на данни и проблеми, свързани с него, като например невъзможността да работят на стойностите на отделните списък стандартни SQL инструменти. Четене и промяна на отделни елементи ще трябва да се приложат начините за кандидатстване.
1.а) съхраняване на данни в една и съща линия с сепаратора. Това е специален случай на опция 1 и минусите на една и съща.
2) Създаване на отделна маса за списъци на ценности.
Опция не харесва факта, че ще трябва да прави справки най-рано през две маси при четене и при писане.
3) Да се съхранява всички данни в една таблица, просто не правете идентификатор низ речника уникален ключ, а след това можете да добавите повече от един запис за същ идентификационен номер.
Не ми харесва факта, че докато трудно да се определи дали позицията е постоянна характеристика или част от списъка. Добавянето специално поле знаме, а-ла-is_list_element - патерица.
Е, и за мен това Вариант 2 (Създаване на отделна маса за списъци на ценности.) Е оптимално и стандарт. Обикновено те се отклони от него само в необичайни ситуации. Не ви съветвам да се измисли велосипед.
Да, най-вероятно, ще трябва да го използвате. Просто се надявам, че пренебрегва някои очевидни и е добър вариант.
Позволете ми да попитам, и съотношението на конвенционалните елементи за списък на нещо влияния?
Сега съм притеснен за друг въпрос. Ще задам два от №2 масата за изпълнение, и таблиците се обърнаха идентична структура, с изключение на уникален индекс в първата таблица.
Т.е. В момента има три полета: идентификатор, CONTROL_ID, стойност.
В таблицата с прости елементи CONTROL_ID трябва да зададете запис в таблицата и в страницата елемент, на които данните ще паднат (учебник). втората таблица CONTROL_ID The изпълнява същата роля за падащите списъци + в тази област, ще трябва да групови записи.
Всичко добро, но почти идентична структура на таблиците води до подозрения :)
Позволете ми да попитам, и съотношението на конвенционалните елементи за списък на нещо влияния? Ако имате само 1% от записите на "списъка" на форма, а само 1-2 двойно на всеки, а след това 99 пъти от 100 ще харчат 2 искания вместо един, и само 1 път се спестят пари за това нещо. Е то си струва?
Това е нещо подобно на кеширане. Ако на кеш паметта е изградена от много време ... и имате 99% кеш за да го удари добре, а ако 1% на кеш, точката в кеш паметта като цяло, не много. С кеша е някак си по-очевидна :)
Всичко добро, но почти идентично на структурата на таблицата води до подозрения Точно така. Вие сте абсолютно прав тук.
Но окончателното решение зависи от данните за действителните. Нормализирането трябва да се прави в полза не на последно място, за да се намали количеството на данните. И в случая с почти пълно дублиране ...
Това означава, че ако имате 10 от средните стойности за всеки клавиш, докато 80% имат ключова стойност от тип "списък", изборът на втория вариант е недвусмислено. И ако списъци са редки и малки, не е уникален като минимум.
Вашият отговор на въпрос
Свързани статии