- SQL
- база данни дизайн
- .NET
- ЕДС
- SQL Server
В онлайн магазина, какви допълнителни параметри на стоките. Краен брой параметри. Много видове стоки. Първото нещо, което идва на ум - образцова архитектура на ЕДС. В интернет пише, че това е лошо и алтернатива - за всеки тип продукт, за да създадете таблица в базата данни.
Бих искал да знам какво е все едно, че е лошо. Истинските причини, които не са измислени, че "не търкайте". И погледнете структурата на базата данни, как да го използвате, ако направите за всеки тип продукт в таблицата си. Както е показано например всички продукти на склад. Всички продукти или червено. Ако има повече от една таблица за всеки тип продукт ... аз не мога да излезе с оптималния схемата.
И все пак ... Аз първоначално знам всички възможни варианти, т.е. 2 маси ще ... Продукти и ProductsDescriptors които записват ProductID (инт), DescriptorID (инт), DescriptorValue (ул). И знам каква самоличност, който съдържа най-творение. Т.е. това не е онлайн магазин за абстрактни стоки и продукти, които познавам. Например DescriptorID = 7 е отговорен за цветен телевизор ...
"Работа" означава извършване на SQL заявка.
ОБЯСНЕТЕ Анализът показва. че искането за придобиване карта конкретния продукт (който разполага с 10 параметри) отнема
0.15 MS. PHP е често мисли за повече от една заявка е изпълнено в PostgreSQL-е.
Имам всякакви умен разбира се не слушат. Аз съм инженер и решаване на конкретни проблеми в конкретни обстоятелства. Предприятията имат слаб интерес към тези технически проблеми. Но представители на бизнеса искат произволен брой видове стоки с всеки набор от характеристики, както и, така че би било, когато нов тип, не е необходимо да се привлекат фирми, които ще бъдат има нещо магическо в структурата на таблицата. И, разбира се, че трябва бързо и bezbagovo работа чрез увеличаване на каталога на един милион позиции.
Тук съм, за да реши тези проблеми. Така че аз имам един прост PHP двигател, който поддържа притока на 300 заявки / сек с час на създаване на страница
0.015 секунди много време (т.е.
25 милиона на ден). В интервала от 5 секунди той може да се справи краткосрочни шипове в търсенето до 1000 искания / сек с поколение
страници
0.070 сек. Така PHP част консумира по-малко от 200 MB оперативна памет. Като цяло, цял куп Nginx + PHP-FPM + PostgreSQL + Redis яде
Ако условията се променят утре, който ще покаже, че ЕДС не ми допадна, ще използвам една по-оптимална структура, без никакви проблеми. И със сигурност не когато не съм религиозен фанатик крещи:% потребителско име%,% Ланг% е вашият лайна и% структура% чудовищен чудовище, защото аз съм инженер и практики. И адекватността на критериите за мен - най-ефективното изпълнение на задачата, а не абстрактни разсъждения теоретици.
Смейте искане код, благодаря ви. След това няма какво да споря с теб, съжалявам.
alekciy, които сте показали изроден случай на ЕДС. Във вашия случай, концепцията за лице - се изроди ненужно predstavlenno отделна таблица. Подобно на структури, наречени UDA (дефинирани от потребителя атрибути) и, наистина, има какво да се притесняваш. В смисъл, че при този модел, пак можете да използвате базата данни на средства за битката за целостта, за разлика от класическия на ЕДС, които е необходимо да се целостта да осигури собствената си, и в условията на конкурентен достъп е Vemma и силно не е тривиална задача и да го решават ефективно, отколкото СУБД за класическа релационния модел, от време на време, това е просто невъзможно.
Въпреки това, прилагането на този подход има своите ограничения, в това, вие очевидно се поберат инча Но в конкретния случай, според мен, рано да се правят обобщения. Всъщност, за да се получи един добър карта, с помощта на този struture не е проблем. Но представете си позиция йерархия в таблица, това е сериозен проблем, трябва да се извърши същия брой се присъединява, атрибутите определя като юридическо лице. Ако трябва да се извърши подбор на само един атрибут или в няколко, като се използва или оператор на предикати, а след това също не е проблем. Но ако трябва да изберете от стойностите на няколко атрибута, предикати селекция с помощта на оператора И, става много problemotichno. Трябва също да се отбележи, че с този подход, дефинирани от потребителя атрибути не могат да се използват в логиката на приложението. защото в жизнения цикъл на приложение атрибут код може да бъде променена от потребителя.
Но фактът, че ЕДС и наистина нищо UDA му няма нищо лошо, напълно съм съгласна с теб. Точно тези структури са с ограничена употреба. И ако UDA все още може да бъде някъде да се използва, в обхвата на ЕДС - незначително. Това са приложения, които работят с отделни лица, модифицирани за изключителен достъп. Мисля, че тази област е най-Stolk стесни този случай, за който се прилага подходът на ЕДС, може да бъде описан като изключително.
> В действителност, може да получи карта на една стока с помощта на този struture не е проблем.
Йерархия в отделна таблица или под формата на AL NS от ситуацията. Връзка с продукта list_dereva чрез трета маса. Тя обхваща съвременните изисквания на бизнеса. По-специално, не се изисква търсене на специфични качества за онлайн магазин за дрехи търсене логика на "Искам червена риза размер XX" обикновено води до бързи ризи примерни използване на индекс и по-бавен, но в рамките на прилагането бързо, филтър от стойностите на атрибутите. Това далеч надхвърля текущите изисквания и с голяма разлика. Ако беше указател Търсене на компютърен хардуер от свойства, и след това, разбира се, няма да бъде използвана такава структура.
За върха на UDA благодарение.
Свързани статии