Witam.

Buduję system ogłoszeń i jest taka kwestia, że różne ogłoszenia będą miały różne pola czyli np.

Nieruchomości - > tytul, powierzchnia, ilosc pokoi, pietro, itp. itd.
Motoryzacja tytul, pojemnosc silnika, itp. itd.
Praca - id_rodzaj_pracy itp. itd.

Mam dylemat. Zastanawiam się czy dla każdych ogłoszeń zrobic calkowicie osobna tabelke czy zrobic jedna ktora ma wspole cechy takie jak np. tytul, osoba_kontaktowa, telefon , a dodatkowe tabelki z dodatkowymi atrybutami.

Czy po prostu dla kazdego rodzaju ogloszenia inne tabelki ?

Jak wy to rozwiązujecie/rozwiazaliscie ?

Weź to na logikę każdy typ ogłoszenia = inna tabela no chyba, że chcesz się męczyć szukaniem pojemności silnika w tabeli gdzie są również zapisane metraże pokoi..

Ja zrobilbym dwie tabele
- jedna ogloszenia - dla cech wspolnych tak jak napisales tytul, osoba kontaktowa itp
- druga specyfikacje ogloszenia - w tym trzymalbym id ogloszenia, nazwe specyfikacji i np wartosc tej specyfikacji, czyli
id | nazwa specyfikacji | wartosc specyfikacji
1 | pojemnosc silnika | 1.8 litra

Przy wyswietlaniu danego ogloszenia wyszukujesz w tabeli "specyfikacje ogloszenia" czy sa specyfikacje o id ogloszenia i jezeli sa to wyswietlasz.

Ewentualnie jedna tabela na zasadzie np tutul, osoba kontaktowa, ... i specyfikacje, gdzie specyfikacje laczysz implodem czyli np ogloszenie nieruchomosci
id | tytul | Osoba kontaktowa | Specyfikacje
1 |Sprzedam | Jakis Pan/Pani | powierzchnia|40m2,ilosc pokoi|3,pietro|2 itp

Pozdrawiam

Zastanów się w inny sposób?

1. Czym są te trzy podane typy ogłoszeń (nieruchomości, motoryzacja, praca)? No w pierwszej kolejności są to po prostu ogłoszenia i jak każde ogłoszenie mogą one mieć swój tytuł, treść, datę publikacji, datę ważności (ew. przedział), swojego autora, są przypisane do jakiejś kategorii - to są dane wspólne dla wszystkich ogłoszeń.
2. Ogłoszenia w różnych kategoriach mają różne atrybuty - ale w sumie atrybut to atrybut: ma swoją nazwę, wartość/ci - ewentualnie jakieś informacje o tym jak wyświetlany daną wartość (przykładowo: powierzchnia mieszkania jest zawsze podawana w metrach kwadratowych czyli jest to wartość liczbowa - jednak wyświetlamy ją w formacie: %d m² - format sprintf))



1. Atrybuty.typ: zawiera informacje o tym czy jest to atrybut typu całkowitego (pow. mieszkania - wartość_int), zmiennoprzecinkowego (wartość_double), tekstowa (wartość_string) - takich typów może być nieco więcej
2. Atrybuty.wielokrotnego_wyboru: flaga informująca czy dany atrybut może przyjąć wiele wartości (np. atrybut "obsługiwane standardy" może przyjąć wartości Abc1, Def2, Ghi-XX2)
3. Atrybuty.format: wspomniany wcześniej format wyświetlania atrybutu, np.: "%d mm" -> "526 mm"
4. Za każdym razem gdy dla danego atrybutu pojawia się wartość, która wcześniej nie wystąpiła wprowadzasz ją do WartościAtrybutów
5. WartościAtrybutów ma niezbyt ładną strukturę, ale daje ona całkiem dobrze radę (lepiej niż osobna tabela na każdy typ wartości) - ma jednak swoje ograniczenia

Utrzymanie takiej struktury jest wyjątkowo niewydajne i ciężkie - a przy wyszukiwaniu czy wielojęzycznym interfejsie można się...

To już w ogóle jest kompletna porażka - zerowa możliwość operacji na danych


Do przechowywania takich danych dosyć dobrze powinna się spisać nierelacyjna baza danych (bo z takimi danymi mamy tutaj do czynienia).

Trochę ciężkie te wasze rozwiązania jak dla mnie. (mały zakres mojej wiedzy).
Oczywiście później chcę wyszukiwać ogłoszenia np. szukaj mieszkanie i można wpisac ilosc pokoi ilosc metrow itp. itd.

A gdybym zrobił to tak:

tabela_nieruchomosci

id, id_ogloszenia, cena, liczba_pokoi, pow_calkowita, pow_uzytkowa, balkon, miejsce parkingowe, internet, taras, winda, gaz, sila, piwnica itp. itd. czy pozniej gdy bede chcial wyszukac np. mieszkania tylko z balkonami to nie bedzie szybciej przeszukiwac?

Dla mnie to najlatwiejszy sposob, ale czy jest on w jakis sposob niepoprawy i moze cos pozniej niewspolgrac? a