🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: pl.comp.www.server-side
6 messages
6 total messages Started by beherit / pn Wed, 17 Nov 2010 10:19
Implementacja parametrów produktów
#61339
Author: beherit / pn
Date: Wed, 17 Nov 2010 10:19
101 lines
4861 bytes
Witam,

mam taką pewną zagwozdkę. Chciałbym wykonać uniwersalny konfigurator 
parametrów produktów przypisanych do kategorii. Np. mamy kategorię 
*lodówki* i wszystkie produkty które dodajemy do lodówek:

1) miałyby parametry:
	- wymagalne
	- opcjonalne
2) parametry dzieliłyby się na typy:
	- text / int / decimal (podawane jako string)
	- select, multiselect / radio, checkbox (wybierany ze słownika 
przypisanego do parametru)
	- text-select (dodawany do słownika danego selecta, jeśli nie zostało w 
nim znalezione)
	- range (podawane jako zakres np. floatów)
	- off (wyłączony w danej akcji)
3) parametry są możliwe do wykonania w akcji:
	- dodawania,
	- wyszukiwania


gdzieś w tym konieczna jeszcze obsługa języka :). Wymyśliłem sobie taką 
strukturę bazy:

nazwy parametrów

CREATE TABLE `param` (
	`_param_id` MEDIUMINT(8) UNSIGNED NOT NULL COMMENT 'Parameter ID',
	`_language` CHAR(2) NOT NULL,
	`_param_name` VARCHAR(64) NOT NULL COMMENT 'Nazwa parametru używana w 
label for, oraz jako nazwa pola.',
	`_param_label` VARCHAR(64) NOT NULL COMMENT 'Label - opis do pola',
	`_type_search` 
ENUM('checkbox','select','radio','range','text','int','decimal','text-select','off') 
NOT NULL COMMENT 'Parameter type',
	`_type_add` 
ENUM('checkbox','select','radio','range','text','int','decimal','text-select','off') 
NOT NULL COMMENT 'Parameter type',
	`_weight` MEDIUMINT(8) UNSIGNED NOT NULL COMMENT 'Important (++ more, 
-- less)',
	`_status` ENUM('ON','OFF') NOT NULL DEFAULT 'OFF' COMMENT 'Czy 
pokazywany w szablonach (oczywiscie musi byc w nich zdefiniowany)',
	UNIQUE INDEX `_param_id__language__param_name` (`_param_id`, 
`_language`, `_param_name`),
	INDEX `FK__node_language` (`_language`),
	INDEX `FK_param_param_type` (`_type_search`),
	CONSTRAINT `FK__node_language` FOREIGN KEY (`_language`) REFERENCES 
`language` (`_language`) ON UPDATE CASCADE ON DELETE NO ACTION
)
COLLATE='utf8_general_ci'
ENGINE=InnoDB
ROW_FORMAT=DEFAULT

słowniki parametrów:

CREATE TABLE `param_value` (
	`_param_id` MEDIUMINT(8) UNSIGNED NOT NULL,
	`_language` CHAR(2) NULL DEFAULT NULL,
	`_param_value_id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
	`_param_value_text` VARCHAR(1024) NULL DEFAULT NULL,
	`_param_value_int` INT(10) NULL DEFAULT NULL,
	`_param_value_float` DECIMAL(12,4) NULL DEFAULT NULL,
	UNIQUE INDEX `_param_id__language__param_value_id` (`_param_id`, 
`_language`, `_param_value_id`),
	INDEX `FK_param_value_language` (`_language`),
	PRIMARY KEY (`_param_value_id`),
	CONSTRAINT `FK_param_value_param` FOREIGN KEY (`_param_id`) REFERENCES 
`param` (`_param_id`) ON UPDATE CASCADE ON DELETE NO ACTION,
	CONSTRAINT `FK_param_value_language` FOREIGN KEY (`_language`) 
REFERENCES `language` (`_language`) ON UPDATE CASCADE ON DELETE NO ACTION
)
COLLATE='utf8_general_ci'
ENGINE=InnoDB
ROW_FORMAT=DEFAULT

iw  końcu miejsce ich przechowywania:
CREATE TABLE `node_param` (
	`_revision` MEDIUMINT(8) UNSIGNED NOT NULL,
	`_param_value_id` INT(10) UNSIGNED NULL DEFAULT NULL,
	`_param_value_text` VARCHAR(1024) NULL DEFAULT NULL,
	`_param_value_int` INT(10) NULL DEFAULT NULL,
	`_param_value_float` DECIMAL(12,4) NULL DEFAULT NULL,
	UNIQUE INDEX `_revision__param_id__param_value_id` (`_revision`, 
`_param_value_id`),
	CONSTRAINT `FK_node_param_param_value` FOREIGN KEY (`_param_value_id`) 
REFERENCES `param_value` (`_param_value_id`) ON UPDATE CASCADE ON DELETE 
CASCADE,
	CONSTRAINT `FK_node_param_node_revision` FOREIGN KEY (`_revision`) 
REFERENCES `node_revision` (`_revision`) ON UPDATE CASCADE ON DELETE CASCADE
)
COLLATE='utf8_general_ci'
ENGINE=InnoDB
ROW_FORMAT=DEFAULT


czy to dobra ścieżka, a może ktoś zna jakieś fajne i ciekawe 
rozwiązanie... bo żeby to zrobić dobrze potrzeba trochę czasu na 
pomyślenie co i jak, a to rozwiązanie takie trochę na szybko.

pozdr,p.
Re: Implementacja parametrów produktów
#61340
Author: William Bonawentura
Date: Wed, 17 Nov 2010 11:39
5 lines
1309 bytes
Generalnie pewnie chciałeś napisać na jakąś grupę o bazach dancyh :). Sama 
idea nie wydaje się być zła, zawsze można ją jeszcze tylko optymalizować. 
Np. może się okazać, że dla wielkości i szybkości bazy danych lepiej założyć 
trzy tabele node_param - oddzielnie dla każdego typu, choć równie dobrze 
koszt nulli może być znikomy. 
Re: Implementacja parametrów produktów
#61341
Author: beherit / pn
Date: Wed, 17 Nov 2010 12:18
26 lines
2271 bytes
W dniu 2010-11-17 12:39, William Bonawentura pisze:
> Generalnie pewnie chciałeś napisać na jakąś grupę o bazach dancyh :).

Pewnie tak :) ale nie miałem zasubskrybowanych, a zapomniałem o opcji 
szukaj. W sumie nie wiem gdzie lepiej czy php czy mysql czy w sumie 
server-side bo to łączy te dwa powyższe :).

> Sama idea nie wydaje się być zła, zawsze można ją jeszcze tylko
> optymalizować. Np. może się okazać, że dla wielkości i szybkości bazy
> danych lepiej założyć trzy tabele node_param - oddzielnie dla każdego
> typu, choć równie dobrze koszt nulli może być znikomy.

W sumie chciałem poznać opinię, mniej więcej czy na pół godziny myślenia 
to będzie dobre rozwiązanie na serwis , który będzie obsługiwał, na oko:
słowników będzie po 2-3 latach: 30,
parametrów do słowników: 5 000,
parametrów niesłownikowych: 200 000,
a wszystko i tak będzie stało na dedyku.

Mała ilość danych, ale kto wie... w końcu nie tylko to będzie tam 
zgromadzone. Mam wrażenie że przy 2000 userach dziennie to i tak nie 
zajmie średnio więcej niż 2% zasobów :).

ps. jakby ktoś miał jeszcze jakieś pomysły to proszę o info :)

pozdr,p.
Re: Implementacja parametrów produktów
#61342
Author: Daniel Podlejski
Date: Wed, 17 Nov 2010 17:25
12 lines
1584 bytes
beherit / pn napisał(a):

>  W sumie chciałem poznać opinię, mniej więcej czy na pół godziny myślenia 
>  to będzie dobre rozwiązanie na serwis , który będzie obsługiwał, na oko:

Zapoznaj się koniecznie z wadami swojego rozwiązania:
http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back
slajdy od 16 do 30 (ale warto obejrzeć całość - wiedza z tych slajdów,
prędzej lub później, przyda się każdemu projektującemu bazy danych)

-- 
Daniel Podlejski
Re: Implementacja parametrów produktów
#61343
Author: beherit / pn
Date: Wed, 17 Nov 2010 18:17
19 lines
1989 bytes
W dniu 2010-11-17 18:25, Daniel Podlejski pisze:
> beherit / pn napisał(a):
>
>>   W sumie chciałem poznać opinię, mniej więcej czy na pół godziny myślenia
>>   to będzie dobre rozwiązanie na serwis , który będzie obsługiwał, na oko:
>
> Zapoznaj się koniecznie z wadami swojego rozwiązania:
> http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back
> slajdy od 16 do 30 (ale warto obejrzeć całość - wiedza z tych slajdów,
> prędzej lub później, przyda się każdemu projektującemu bazy danych)
>
Fajnie pomyślane ale IMHO dłuższe w implementacji  - wymagałoby 
stworzenia kreatora tabel dla różnych zestawów atrybutów.

Na pierwszy rzut oka ciężko mi sobie wyobrazić w jaki sposób stworzyć w 
tym słownik atrybutów i zapisywać w bazie np. te z możliwością 
wielokrotnego wyboru? Poradzisz?

P.
Re: Implementacja parametrów produktów
#61344
Author: William Bonawentura
Date: Thu, 18 Nov 2010 09:25
12 lines
1563 bytes

Użytkownik "beherit / pn" <beherit@sprawdzam-raz-w-miesiacu.firenet.eu.org> 
napisał w wiadomości news:ic0h79$62n$1@inews.gazeta.pl...
>
> Pewnie tak :) ale nie miałem zasubskrybowanych, a zapomniałem o opcji 
> szukaj. W sumie nie wiem gdzie lepiej czy php czy mysql czy w sumie 
> server-side bo to łączy te dwa powyższe :).
>

IMHO na tej grupie nie dyskutuje się o tematach związanych z aplikacjami 
tylko co najwyżej technologiami. Czyli pytnie o pulę połączeń do mysql 
byłoby ok, o model tabel - już nie bardzo :).
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads