Cześć

Jak najlepiej zarządzać zdjęciami w bazie danych? Powiedzmy, że chodzi o sklep, w którym są produkty poukładane w różnych kategoriach. Każdy produkt może mieć zdjęcia (albo ulotki pdf). Oczywiście produkt ma też opis, nazwę. Jak zaprojektować taką bazę w której każdy produkt może mieć różną liczbę zdjęć? Wymyśliłem sobie takie proste rozwiązanie

tabela zdjecia
PRODUCT_ID | FOTO_NAME

i jeśli produkt ma kilka zdjęć to kilka razy pojawi się jego id w tej tabeli ale różne będą nazwy zdjęć. Jest jeszcze sprawa kolejności zdjęć. Jedyne na co wpadłem to dodatkowa kolumna ORDER. Pobierałbym nazwę zdjęć dla danego PRODUCT_ID i sortował według kolumny ORDER. Ale może macie jakiś lepszy pomysł?

I na koniec, czy zdjęcia trzymać w folderze danego produktu, czy jakoś inaczej to poukładać? Teraz mam folder BASE/XXXX i każdy produkt ma swój własny folder (taki jak PRODUCT_ID). Tylko, że jeśli produkty mają takie samo zdjęcie to musiałbym je mieć powtórzone w każdym folderze - spory minus.

Jak to rozplanować, żeby było lepiej.

pozdro

Tworzysz tabelę zdjęć:
ID | NAZWA | URL | czy cokolwiek tam jeszcze potrzebujesz

Następnie w tabeli PRODUCTS_IMAGES
PRODUCT_ID | IMAGE_ID | ORDER

nakładasz unikatowy klucz na (PRODUCT_ID, IMAGE_ID) - żeby nie duplikować wpisów

Zdjęcia przechowujesz w jednym katalogu. Bo może się zdarzyć, że będziesz miał zdjęcie, które będzie pasować do kilku produktów (ta sama seria notebooka), wtedy nie musisz go kopiować x razy.

Nazwy plików rób unikatowe, nie takie jak przy wgrywaniu, użyj np: md5_file

Możesz też zrobić, że id zdjęć wrzucisz do kolumny w tabeli produktu, np po przecinku (1,2,3,15). Tyle, że ta opcja wg mnie daje mniejsze możliwości manipulacji. Chociaż zapisując, możesz zapisywać wg ważności.

vokiel no właśnie o czymś takim myślałem.
1 tabelka zdjęć: FOTO_ID | name | path
2 tabelka produktów: PRODUCT_ID | name | description | i inne ...
3 tabelka łącznikowa: PRODUCT_ID | FOTO_ID | ORDER

I oczywiście nie będzie zdublowanych zdjęć o czym pisałeś. Ale pojawia się problem optymalizacji. Co jeśli folder zdjęć będzie miał bardzo bardzo wiele plików? Czy wtedy nie lepiej sprawdza się trzymanie zdjęć z folderach produktów? Mam takie foldery bo gdzieś muszę trzymać pliki pdf i doc. Niby mógłbym zrobić analogicznie takie samo rozwiązanie dla zdjęć, pdf, doc i każdy rodzaj plików trzymać w jednym katalogu + odpowiednie tabele w bazie. Tylko znowu jest pytanie o to czy warto unikać zdublowanych plików za cenę całej tej roboty? Jak uważasz?

A i jeszcze jedno. Te pliki pdf i zdjęcia mają się zmieniać w zależności od wersji językowej. Troszkę nie wiem jak to ogarnąć po uwzględnieniu różnych języków. Jak to na dysku trzymać? Posegregowane rodzajem dokumentu, czy językiem, czy produktem do którego dany dokument jest przypisany?

pozdro

Hej

Widzę 2 rozwiązania:

1. Umieszczenie plików dla każdej wersji językowej w osobnym podkatalogu o nazwie równej "pl", "en". W aplikacji ustawianie znacznika wersji np.: "pl", "en"... Później doklejanie tego znacznika do ścieżki do pliku.
2. Trzymanie wszystkich plików w jednym katalogu, ale doklejenie na końcu ich nazw odpowiedniego sufiksu określającego wersję językową.

Wybór należy do Ciebie

Z doklejaniem nazw do plików wolę uważać, żeby nie było błędu jeśli nazwa pierwotnie zawiera prefix/sufix języka. Czyli zostają katalogi pl i en. Ale nadal jest pytanie czy dla poszczególnych produktów robić katalogi na dysku, a w nich podkatalogi językowe? Czy dla wszystkich produktów w sumie dwa katalogi polski i angielski? A poszczególne pdf albo zdjęcia identyfikować tylko po ich unikalnej nazwie + tabela łącznikowa. Jak lepiej będzie? Niby najwygodniej mieć tak jak pisał vokiel ale trochę obawiam się katalogów po kilka tysięcy plików (np katalog zdjęć). Może można jakoś inaczej?

pozdro

Odnośnie języka to najlepiej w oddzielnych katalogach pl, en itd. Najłatwiej się później tym operuje, bo po prostu dostawiasz do ścieżki $lang.

Sprawa wydajności listowania katalogów z tysiącami plików.
Na pewno będzie szybciej jeśli tych plików będzie mniej. Ale też, jeśli będzie bardzo dużo katalogów to się w rezultacie sprowadzi do tego samego - listowania dużej ilości, z tym, że katalogów.

Opcja 1. Katalog na każdy produkt, a w nim wszystko wrzucone jak leci (oznaczenie języka przez postfiks: opis_pl.pdf)
Opcja 2. Katalogi językowe /pl /en, a w nich katalogi na produkty, dalej jw
Opcja 3. Katalogi językowe jw, w nich katalogi na poszczególne rodzaje danych (pliki pdf, pliki doc, zjecia etc)

Każda z tych opcji powoduje, że na którymś etapie będzie albo dużo plików w katalogu, albo dużo katalogów.

No i tak dochodzimy do pomysłu (IMHO) najbardziej optymalnego. Podział katalogów w jakiś bardziej ogólny sposób (wg daty dodania, liter alfabetu) tak, aby dało się to podzielić na niezbyt duże (pod względem zawartości elementów) grupy.

Wybór zależy od kilku czynników:
- produkty dodawane stale, coraz nowsze
- produkty dodane raz, na początku, następnie tylko kosmetyczne zmiany, lub niewielka ilość nowych
- produkty, których nazwy są różnorodne, dają w miarę równomierny rozkład alfabetyczny

Analizując powyższe łatwiej jest się zdecydować na formę przechowywania. I tu, jako, że już i tak sporo napisałem, pozwolę sobie na własną opinię:
1. Nazwy różnorodne - wtedy podział na litery alfabetu czyli:


2. Nazwy jakkolwiek, dużo na literę A, prawie brak na R - katalogowanie na podstawie daty dodania


Każdy produkt kiedyś tam został dodany. Dobrze mieć datę dodania w bazie, i na jej podstawie określamy położenie plików: /pl/2009/01/img/md5_z_nazwyproduktu.jpg
BTW. Dodatkowo można zastosować podział na rodzaj pliku (pdf, doc, img etc).

Dzięki temu nie będziemy mieli w jednym katalogu np 2k plików, ani nie będziemy mieli 2k katalogów. Podział będzie logiczny, tak, że nawet nie znając algorytmu można będzie z palca coś odnaleźć.

Pozdrawiam

vokiel bardzo dziękuję za wyczerpującą odpowiedź. No mały wykładzik strzeliłeś!

Mam jeszcze takie wątpliwości:

1 Ile plików albo folderów jest do przyjęcia, żeby nie było dużych spowolnień? Na pewnie mniej niż 5000 no ale ile? 100, 200, 500, 1000? Czy wielkość tych plików albo folderów ma wpływ?

2 Jeśli produkty identyfikuje po ID a nie po nazwach, to pozostaje mi tylko podział ze względu na daty? Kolejne produkty mają ID = 1,2,3, ...

3 Podział datami ma pewien minus. Powiedzmy, że w 2007 dodałem ID = 1234 (produkt i kategoria są nierozróżnialne) następnie dodawałem właściwe produkty. I w 2010 okazuje się, że żaden z właściwych produktów z 2007 nie jest już sprzedawany. Ale muszę trzymać folder "wydmuszkę" z roku 2007 bo jest w nim kategoria która jest aktualnie używana dla nowszych produktów. Chodzi mi o to, że podczas usuwania starych produktów na dysk struktura niekoniecznie będzie się tak ładnie upraszczać.

4 Co zrobić jeśli ani podział datami ani alfabetyczny się nie sprawdzi? Alfabetyczny odpada ze względu na identyfikacje produktów po identyfikatorach, nazwy są tylko gdzieś w bazie. Nazwy mogą się zmieniać np w wyniku błędu wprowadzania do bazy, zwykłej literówki - dlatego nie chce ich używać. A identyfikatory się nigdy nie zmieniają. A daty odpadają bo może być miesiąc kiedy dojdzie 1500produktów a może być pół roku kiedy nie dojdzie żaden.

5 Czy warto używać czegoś innego niż md5_file dla generowania nazw plików?

pozdro

Ad. 1
Najlepiej to sprawdzić, porównać sobie czas i wybrać optymalne rozwiązanie.

Ad. 2
Jeśli po id to nawet lepiej, zapisujesz nazwę jako id + rozszerzenie.

Ad. 3
Pisząc o kategoriach miałem na myśli kategorie plików: dokumenty, obrazki, instrukcje (lub po prostu rozszerzenia pdf, doc, jpg)

Ad. 4
Słuszna uwaga, nie pomyślałem o zmianie nazwy produktu

I tu pomysł z ID wydaje się jeszcze lepszy :-)
Dziel po ID na grupy po np 200, czyli katalog 200 będzie zawierał produkty o id <200, katalog 400 będzie zawierał produkty o id >= 200 i id<400

Ad. 5
Jeśli masz unikalne id, to samo id by wystarczyło (jeśli nie masz 2 plików tego samego rodzaju - bo jeśli tak, to jednak nazwa musi pozostać unikalna)

vokiel wiem, że jest późno i mogę bredzić ale czy twój avatar to nie jest z tej kreskówki o kurach które dziergają sweterki? Jak ona się nazywała? Nie mogę sobie przypomnieć.

A wracając do sprawy:

1 Pytałem o Twoje doświadczenia, bo pewnie są większe niż moje. A to troszkę też od sprzętu zależy. Na moim kompie 300 plików/katalogów jest do przyjęcia. Ale na serwerze Fedora + Phenom X4 już bliżej 1000 plików/katalogów.

2 Produkt identyfikuje po ID a nie nazwie. Ale, że każdy produkt może mieć dowolną ilość plików jakiegoś typu (pdf, doc, ...) to nazwy plików muszą być unikalne i ID tego nie zapewni.

3 Faktycznie, małe nieporozumienie. To, że dzieli pliki na powiedzmy 'typy' albo 'rodzaje' to jest dla mnie oczywiste. Osobny folder na fotki, osobny na doc, osobny na polskie pdf i osobny na angielskie pdf i tak dalej

4 No zmiany nazw związane z literówkami to istny koszmar. Ale poza tym, jeśli produkt (LG 22" superLCD) jest nierozróżnialny (poza posiadaniem potomków) od kategorii (Monitory LCD), to z czasem nieuniknione są zmiany nazw bardziej świadome, że tak powiem. 'Monitory LCD' na 'Monitory' bo CRT już chyba nawet nie ma w sprzedaży. Może to nei najlepszy przykład nie śledzę rynku sprzętu komputerowego ale chyba wiesz o co mi chodzi.

Mówisz, żeby dzielić po ID? Np foldery '0000-0200', '0201-0400', '0401-0600' i dopiero w nich odpowiednio 'jpg', 'pdf', 'doc'?

5 Tak jak pisałem wyżej, samo ID nie wystarczy. Czy poza md5_file() jest coś wartnego uwagi?



Tak sobie myśle, że zapytam jeszcze o:

6 Jak rozwiązujesz sprawę kilku struktur dla tych samych danych? Np sklep komputerowy i są w nim nagrywarki, monitory, dyski i inne. Czyli hierarchiczna struktura z przodkami i potomkami. Ale są też producenci np NEC, WD, SAMSUNG. I powiedzmy, że jakiś fanboy chce poskładać kompa z częściami tylko jednego producenta. Jak umożliwić mu przeglądanie części ale właśnie z nazwami producentów jako najogólniejszymi kategoriami? Czyli

XTRA FIRMA
--- dyski
--- sata
--- ata
--- ram


pozdro

Uciekające kurczaki? Chyba nie, zresztą już nie pamiętam skąd go mam, mam go dość długo.

Ad. 4
Zmiana nazwy produktu nie powinna pociągać za sobą zmiany nazwy pliku, w ogóle, jeśli plik pozostaje ten sam to pozostaje nietknięte.

Właśnie coś takiego

Ad. 6
To już nie ma związku ze strukturą katalogów. Tu już tylko baza.

W każdym produkcie tworzysz pole producent. Jeśli ktoś chce produkty jednego producenta pobierasz wszystkie z warunkiem dla wybranego producenta, a wyniki grupujesz wg kategorii.

[SQL] pobierz, plaintext 
SELECT * FROM `PRODUCTS` WHERE `MANUFACTURER`='ASUS' GROUP BY `CATEGORY` ORDER BY `NAME` DESC
[SQL] pobierz, plaintext 

o właśnie o uciekających kurczakach myślałem

4 I dlatego nie chciałem dzielenia bazy według nazw produktów.

6 A to podobnie robimy, z tym, że zwykle struktura kategorii ma kilka poziomów. Dlatego ja pobieram całą tabelę produktów z warunkeim
WHERE `MANUFACTURER`='ASUS'
do PHP, a potem rekurencyjnie ją wyświetlam. Tak jak wyświetlam menu. Chyba dobrze robię?

Dzięki za pomoc, no gdybym mógł to postawiłbym Ci grillowane udko z uciekającego kurczaka


pozdro

Grillowane udko - z chęcią mam parę browarków pod ręką - będzie jak znalazł
No a jeśli nie udko to zwykłe "Pomógł" też wystarczy

vokiel jeszcze 3 pytanka mam do ciebie, jeśli można ovcourse

1 Jak masz jakieś produkty, które mają wystąpić w kilku kategoriach jednocześnie, czyli relacja n do n, to jak to robisz?
Bo jeśli w tabeli z produktami mam kolumny ID, PARENT_ID, DESCRIPTION i inne, to ID nie może być głównym kluczem, bo by się powtarzał. A właśnie ID pasuje mi jako główny klucz najbardziej. Co więc zrobić?

2 Jakie możliwości implementujesz w swoich panelach do bazy? Na pewno:

dodawanie produktu:
wybór rodzica
wklejenie: nazwy, opisu
wybór albo wklejenie producenta
upload zdjęć
wybór z już wgranych zdjęć
data wpisuje się z automatu

modyfikowania produktu:
wklejenie albo wybór: nowej nazwy, opisu, producenta
upload nowych zdjęć
wybór z już wgranych zdjęć
wybranie nowego rodzica (jeśli ten produkt ma potomków to im zmieniają się automatycznie wszyscy przodkowie)

usuwanie produktu: wiadomo

Do tego mały panel do przeglądania zdjęć:
wszystkich
wybranego produktu
wybranej gałęzi
+sortowanie po wielkości, dacie


I co najważniejsze jak przeglądasz bazę? Wyświetlenie tabeli ze wszystkimi produktami odpada, bo to za dużo. Wybierasz gałęzie w drzewie, czy jakoś inaczej?


A może właśnie jakoś inaczej to robisz? Pewnie można to jakoś lepiej zaplanować. Tylko jak?



pozdro

Tylko 3?

1.

Tabela kategorii (id, nazwa, etc)
W produkcie gdzie masz pole kategorii możesz wpisać je po przecinku, na zadzie tagów, tak aby produkt mógł należeć do wielu kategorii na raz

Ewentualnie standardową relacje wiele-do-wielu poprzez trzecią tabelę:
Kategorie (id, nazwa, etc)
Produkt (id, nazwa, etc)
Kategorie-produkty (id_kategorii, id_produktu) -> klucz na (id_kategorii, id_produktu)

2. INSERT, DELETE, EDIT
Takie standardowe raczej, większość operacji na danych odbywa się poprzez takie funkcjonalności. Oczywiście dochodzi wyszukiwanie

Funkcjonalności powinno być tyle ile trzeba żeby było.

Dodanie/edycja - IMHO - powinno odbywać się na tym samym formularzu - te same opcje, te same funkcjonalności.

W tym przypadku widzę takie, główne moduły: produkt (przeglądanie, dodawanie, usuwanie, edycja), biblioteka mediów (przeglądanie, dodawanie, usuwanie, edycja). Dodatkowo można zrobić mniejsze: producenci, grupy, tagi.

Przykładowo wybór producenta odbywa się na stronie dodawania/edycji produktu. Masz np listę rozwijalną producentów, i jeśli taki się na niej nie znajduje, to pole obok w które można go dodać. Tak, żeby dodanie produktu mogło się odbyć za jednym razem.

3. (choć numerku nie było )
Bazę przeglądam programem SQLyog
A w panelu, w przypadku podziału na kategorie, drzewko kategorii z jednej strony, a na głównym ekranie przeglądania możliwość sortowania po każdej kolumnie, do tego stronicowanie wyników z możliwością wyboru ilości na stronie (to wszystko dzięki lasie nospora - pager)

Można, na pewno. Z każdym projektem przychodzą do głowy lepsze rozwiązania. Kiedyś myślałem, że jak się już napisze tego kodu, to później się już tylko wybiera gotowe moduły i składa w całość. Jednak nie do końca, tym bardziej jak się pracuje na aplikacjach, które się napisze. Z czasem, w trakcie użytkowania przychodzą nowe pomysły, usprawnienia, nowe zapotrzebowania etc)

Odpozdrawiam

Sorry przepraszam za te pytania ale widzę, że znasz się na pehapie i sql i co więcej dzielisz się wiedzą

Tego nie jarzę: klucz na (id_kategorii, id_produktu) - klucz na dwie kolumny?

Nie jestem pewien ale czy chodzi o ci o tabelkę z kolumnami product_id, parent_id i nie rozróżnia się produktu od kategorii, i można otrzymać wielopoziomową strukturę? Czy może jednak jakoś szczególnie traktujesz kategorie?

Widzę, że panel mam raczej podobny do twojego. Więc myślę, że u mnie jest ok

Na razie jedynie z tabelami w bazie mam ból. Dostaje je w xls albo csv i zamieniam przy imporcie do bazy na tabelki html. Ale dostaje białej gorączki jak trzeba je modyfikować. Wysyłam je do przeglądarki znowu zamienione na csv, edytuję w excelu. Potem znowu upload do bazy. Proste poprawki można zrobić w kodzie ale zamiany i edycje kolumn to na prawdę boli bez excela. Ale z tego co szukałem to nikt się edytowaniem kolumn w tabelach nie uprał w inny sposób.

Też tak myślałem o modułach. Ale szybko doszło do mnie, że to się co chwile zmienia. Raz inny interface -PDO- do bazy a raz nowa funkcjonalność. A jakieś pół roku temu reorganizacja bazy (wygenerowanie wszystkich przodków dla każdego produktu, żeby ładnie na stronie się wyświetlało gdzie teraz jest user - żeby się nie zgubił)

pozdro


edit

Zapomniałem spytać o to jak radzisz sobie z nazewnictwem kolumn i tabel. Powoli w bazie robi się pełno tabel i pełno identyfikatorów. Jasne, że dodaje się do "ID" postfix "_zdjecia" albo prefix "foto_" ale czy masz jakiś schemat? Albo czy wyróżniasz jakoś główną tabelę w której masz produkty (chyba ona jest njaważniejsza) poprzez nie sotsowanie tych postfixów lub prefixów zostawiając samo "ID" albo samo "time"?

btw
Jak jest ze znakami dozwolonymi w sql dla nazw tabel i kolumn. Alfanumeryczne i podkreślenia. A znaki plus i minus i inne? Można we wszystkich bazach, czy mogą być problemy?

Widzę, że się rozkręciłeś

Klucz główny zakładasz na oba pola razem, dzięki temu nie będziesz miał dwóch takich samych wpisów, czyli nie wpiszesz 2x że produkt A należy do kategorii B.

Nie widzę potrzeby parent_id. Konkretny produkt nie jest potomkiem kategorii, on tylko do niej należy. Bardziej jest już potomkiem producenta. Do produktu przypisujesz kategorię (kategorie), do której (których) należy. Strukturę drzewiastą implementujesz do kategorii.


Używasz excela do modyfikacji kolumn w bazie? A o jakiej bazie tu mówimy?

Nazewnictwo kolumn, tabel, baz - raczej z angielskiego, tak aby w miarę logicznie opisywały zawartość. Z czasem przyzwyczaiłem się do używanego nazewnictwa i nawet się już nie zastanawiam. Same nazwy zwykle w jednej notacji, np nazwy kolumn wielkimi literami, litery i podkreślenia. Nigdy nie miałem potrzeby używania innych znaków, raczej się tego wystrzegam. Kiedyś się mówiło nawet, że polskie znaki w nazwach plików to patologia;) Nie sprawdzałem ile z 'innych' znaków, z których nie korzystam przejdzie, a ile nie. Raczej nie wszystkie, ponieważ część zastępuje np dowolny znak, wiele znaków itd (. ?). Zatem budowanie zapytań sql mogłoby później powodować niezłe komplikacje.

Prefiksy zawsze tak samo. Dzięki temu później w zapytaniach się nie zastanawiam czy to jest tabela_kolumna, czy kolumna_tabela
PRODUCT (ID, NAME, TYPE)
CATEGORY (ID, NAME)
PRODUCT_CATEGORY (PRODUCT_ID, CATEGORY_ID)

No się rozkręciłem

1 Właśnie nie wiem jak założyć klucz główny na dwie kolumny? Przy definicji w obu kolumnach pisze PRIMARY KEY?

2 Czyli rozróżniasz kategorie od produktów? Ja do tej pory tego nie robiłem. Stosowałem drzewiasta strukturę do produktów (produktem też była kategoria).
Mówisz, że lepiej zrobić tabelę category( id, name, parent_id ), tabelę product_category( product_id, category_id) i oczywiście tabelę products(id i inne)
Faktycznie jest w tym logika. Trochę mi się skomplikują zapytania, ale chyba tak będzie lepiej ?

3 Spokojnie baza jest oparta o SQL. Ale niektóre z produktów mają jakieś tabelaryczne opisy dostarczane w plikach excela. I niestety muszą być na stronie. Stąd moje zmagania z kolumnami w excelu. Dostaje plik xls/csv i szefuńcio chce go widzieć jako tabelkę na stronie. Ale za tydzień przybiega, że może by zamienić kolumny. Albo dodać coś do tej tabeli. Rozumiesz?

4 Ja właśnie się waham, teraz używam polskich (bez ą, ę i innych) nazw i nawet mi pasuje. Ale co jakiś czas myślę czy nie przejść na anglojęzyczne nazwy.

5
PRODUCT (ID, NAME, TYPE)
CATEGORY (ID, NAME)
PRODUCT_CATEGORY (PRODUCT_ID, CATEGORY_ID)
Ja staram się o to aby nazwy kolumn były wszędzie takie same:
PRODUCT (PRODUCT_ID, NAME, TYPE)
CATEGORY (CATEGORY_ID, NAME)
PRODUCT_CATEGORY (PRODUCT_ID, CATEGORY_ID)
Ale nie wiem czy to nie przesada, jak uważasz?

A z tym
tabela_kolumna, czy kolumna_tabela to zawszę się mylę i nigdy nie wiem czy mam PRODUCT_CATEGORY czy CATEGORY_PRODUCT.

pozdro

edit

2 Po chwili zastanowienia mam poważne wątpliwości co do sensu rozróżniania produktów i kategorii. Oczywiście stworzenie struktury w osobnej tabeli jest dobre i kolumna parent_id powinna być tylko tam a nie w głównej tabeli z produktami. Ale jaki jest sens rozdzielania produktów od kategorii? Widzę natomiast już jedną wadę, przy drzewkach IP albo podobnych strukturach nawigowanie po dwóch tabelach jest trudniejsze. Np chce wypisać wszystkich przodków danego produktu (coś w rodzaju adresu IP) to mając nierozróżnialne produkty i kategorie zrobię to łatwo. A jeśli je rozróżniam, to najpierw muszę pobrać adres IP kategorii i potem dokleić id produktu. Niby niewielka komplikacja ale jednak. Jaki zatem zysk z tego rozdziału? Przecież i tak kolumny będą identyczne w obu tabelach ( name, description ). I będzie trzeba zrobić podobne tabele łącznikowe product-img, category-img, product-pdf, category-pdf. Może ja ślepy jestem ale strasznie się zagęści liczba podobnych tabel. Warto?

pozdro

btw
a znak myślnika jest dozwolony w nazwach tabel/kolumn we wszystkich bazach SQL?

Ad. 1.

[SQL] pobierz, plaintext 
DROP TABLE IF EXISTS `PRODUCT_CATEGORY`;
CREATE TABLE `PRODUCT_CATEGORY` (
  `PRODUCT_ID` int(11) NOT NULL,
  `CATEGORY_ID` int(11) NOT NULL,
  PRIMARY KEY  (PRODUCT_ID, CATEGORY_ID)
)  type = MyISAM
CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT CHARSET=utf8;
[SQL] pobierz, plaintext 

Ad. 2. Tak, rozdzielam. Dla mnie kategoria to kategoria, a produkt to produkt. Ale Ty nie musisz, jeśli Tobie jest wygodniej tak jak masz, łatwiej na tym pracować, mniej komplikacji to na prawdę zostań przy swojej wersji, po co masz się męczyć z czymś co Ci nie leży.

Nie trzeba robić tabeli product_category, można kategorie wypisać po przecinku w tabeli PRODUCT.

Ad. 3. Czyli tu chodzi o opisy produktu, a nie o strukturę tabel samej bazy

Ad. 4. Ważne, żebyś miał stały, konkretny system, którego się będziesz trzymał. Ten sam język, ustalona wielkość liter, używanie podkreślników, myślników etc. Później jak ktoś do tego będzie musiał się dobrać, albo nawet Ty sam, żeby nie trzeba było się zastanawiać pół dnia jak to jest zorganizowane.

Ad. 5. PRODUCT (PRODUCT_ID, NAME, TYPE)
Ja nie lubię takiego zapisu, bo gdy wyciągasz id z tabeli product to musisz pisać: PRODUCT.PRODUCT_ID - co jest wg mnie masłem maślanym PRODUCT.ID jest bardziej zwięzłe a i tak zachowuje swoje znaczenie i wiadomo co z czego.

Ustal sobie raz konkretnie z którego sposobu korzystasz i się tego trzymaj wszędzie, z czasem się przestaniesz zastanawiać.

Ad. edit
Tak jak pisałem wyżej, jeśli wolisz swoje rozwiązanie to zostań przy nim, na prawdę, nie ma sensu zmieniać rozwiązania, które się sprawdza, które dobrze rozumiesz, znasz na pamięć.

Nie wiem, czy wszystkie pozwalają, nie sprawdzałem we wszystkich, nawet nie potrafię wszystkich wymienić. Ja osobiście używam zestawów [a-zA-z_] i nigdy nie miałem z tym problemów

Ja osobiście staram unikać myślnika z prostej przyczyny: wprowadza bazę w błąd w pewnych wypadkach. Z przyzwyczajenia po SELECT używam nazw kolumn nie ujętych w żadne apostrofy i przez to nazwa-kolumny jest "widziana" jako różnica wartości kolumn: nazwa, kolumny. A takich w bazie nie ma i jest problem, gdyż zapytanie się wykrzaczy Albo więc nie ujmujesz nazw w nic i unikasz myślnika, albo ujmujesz je w apostrofy i zlewasz znaki w nazwie.

ad 1 już wiem

ad 2 po namyśle zostaje przy swoim podejściu

ad 3 Tak, tabelki z excela to część opisu produktu. Wszelkie sposoby na uporanie się (educja kolumn) z tym gównem mile widziane.

ad 4 Powoli go tworzę.

ad 5 Masz racje, wygląda to strasznie. Twoja wersja lepsza.

dzięki again

pozdro

Ad. ad 3.
Co do opisów produktów dodaj może sobie edytor WYSIWYG na stronę (tinyMC, fckEditor), wtedy nie będziesz musiał grzebać w kodzie tych tabelek

Ale one chyba nie zapewniają nawet podstawowych funkcji arkusza kalkulacyjnego? Do edycji tekstów używam zwykłych formularzy z ręcznie wstawianym bbcode. Nie znam na razie javascript (dopiero zaczynam się uczyć). Więc tak ładnego klikania bbcode jak na tym forum nie napiszę. Ale na razie to nie jest duża trudność. Przede wszystkim chodzi o pliki csv. One zawierają kolumny i wiersze tak jak normalna tabela. I problem jest jak mam zamienić kolumnę 3 z kolumną 5. Muszę wysłać plik do przeglądarki, otworzyć w desktopowym arkuszu, zapisać na dysku, uploadowac na serwer. To chciałbym obejść. Wiesz może jak?


pozdro