[mysql] baza aut
albert - 13-09-2007 00:04
[mysql] baza aut
Mam 5 tabel do bazy aut. Może mi ktoś powiedzieć czy są one optymalne i ew.
wskazać błędy?
RODZAJE
ID_RODZAJU int(4)
rodzaj varchar(20)
Gdzie 'rodzaj' to samochody osobowe, samochody cięzarowe, samochody
uszkodzone, starocie.....
+++
MARKI
ID_MARKI int(6)
marka varchar(20)
parent tinyint(1) (0 lub 1)
Gdzie 'marka' to AUDI,80,90,100,200....z tym że AUDI ma 'parent' 0 czyli
rodzaj auta, a 80,90,100... 'parent' 1 czyli model auta
+++
NAMIARY
ID_GMINY int(6)
woj_gmina varchar(40)
parent tinyint(1) (0 lub 1)
Gdzie 'woj_gmina' to Zachodniopomorskie,Świnoujście,Człopa,Mirosławiec. ...z
tym , że Zachodniopomorskie ma 'parent' 0 czyli głowne(województwo), a
Człopa, Mirosławiec 'parent' 1 czyli gmina
+++
POJAZD
id_pojazdu int
ID_RODZAJU
ID_MARKI
typ varchar(30) (sedan,kombi...)
cena int
cena_do_negocjacji tinyint(1) (0 lub 1 - tak/nie)
rok_prod int(4)
pojemnosc_silnika int(4)
moc_silnika int(3)
przebieg_km int(6)
skrzynia varchar(15) (automat,normalna)
paliwo varchar(15) (diesel,benzyna,benzyna+lpg)
ile_drzwi tinyint(1) (2,3,4,5)
kolor varchar(30)
kolor_metalic tinyint(1) (0 lub 1 - tak/nie)
data_1_rej varchar(7)
waznosc_przegladu varchar(7)
waznosc_ubezpieczenia varchar(7)
opis pojazdu text
imie_nazwisko_sprzedajacego varchar(70)
prywatnie_komis_dealer tinyint(1) (1,2,3)
ID_GMINY
miasto varchar(30)
email varchar(70)
telefon varchar(10)
telefon2 varchar(10)
INNA TABELA?????
auto posiada:
abs tinyint(1) (0 lub 1 - tak/nie)
alarm tinyint(1) (0 lub 1 - tak/nie)
alufelgi tinyint(1) (0 lub 1 - tak/nie)
........
itd.
informacje_dodatkowe:
homologacja_na_ciezarowe tinyint(1) (0 lub 1 - tak/nie)
bezwypadkowy tinyint(1) (0 lub 1 - tak/nie)
garazowany tinyint(1) (0 lub 1 - tak/nie)
........
itd.
+++
ZDJECIA
id_foto int
id_pojazdu int
nazwa_pliku varchar(12)
Biorąc pod uwagę, że mogą to być tylko pliki .jpg to chyba nawet nie musi
być 'nazwa_pliku' bo nazwę pliku można tworzyć wg id_foto dodając tylko do
niego .jpg
++++++++++++++++++++++++++
Czy taki układ tabel jest optymalny? Nie wiem czy w namiary nie lepiej jest
zmienic gminy na powiaty bo gmin jest ponad 2000 a powiatów 300. Może w
ogole zrezygnować z tabeli namiary i obok info o miejscowości, którą wpisuje
user dodać też selecta do dodania województwa, które też będzie wpisywane w
tabeli POJAZD?
Co zrobić z informacjami o wyposażeniu auta bo żeby każda opcja miała swoje
pole 0 lub 1 to jest raczej poroniony pomysł, nawet w osobnej tabeli? Może
lepiej w tabeli POJAZD, ale dać pole ENUM tylko czy to pozwoli szybko
wyświetlic zapytanie o pojazdy z np. alufelgami?
Czy idąc dalej można zamienić pole tinyint(1) na pole SET i czy to nie
opóżni wyszukiwania?
chester - 13-09-2007 00:04
albert pisze:
> Mam 5 tabel do bazy aut. Może mi ktoś powiedzieć czy są one optymalne i ew.
> wskazać błędy?
> auto posiada:
> abs tinyint(1) (0 lub 1 - tak/nie)
> alarm tinyint(1) (0 lub 1 - tak/nie)
> alufelgi tinyint(1) (0 lub 1 - tak/nie)
> .......
> itd.
A ja się podepnę.
Czy lepiej stosować tinyint, czy może ENUM('0','1') ?
Które rozwiązanie z punktu widzenia 'optymalności' jest lepsze pod kątem:
a) semantyki (tinyint może mieć więcej wartości)
b) rozmiaru rekordu liczonego w bajtach
c) wyszukiwania wg kryterium (czyli: WHERE abs=1 vs. WHERE abs='1')
chester
=?ISO-8859-2?Q?Pawe=B3_Matejski?= - 13-09-2007 00:04
albert wrote:
> Mam 5 tabel do bazy aut. Może mi ktoś powiedzieć czy są one optymalne i ew.
> wskazać błędy?
>
> RODZAJE
> ID_RODZAJU int(4)
> rodzaj varchar(20)
>
> Gdzie 'rodzaj' to samochody osobowe, samochody cięzarowe, samochody
> uszkodzone, starocie.....
> +++
>
> MARKI
> ID_MARKI int(6)
> marka varchar(20)
> parent tinyint(1) (0 lub 1)
>
> Gdzie 'marka' to AUDI,80,90,100,200....z tym że AUDI ma 'parent' 0 czyli
> rodzaj auta, a 80,90,100... 'parent' 1 czyli model auta
Przesadziłeś, rozbij to na dwie tabele.
> +++
> NAMIARY
> ID_GMINY int(6)
> woj_gmina varchar(40)
> parent tinyint(1) (0 lub 1)
>
> Gdzie 'woj_gmina' to Zachodniopomorskie,Świnoujście,Człopa,Mirosławiec. ...z
> tym , że Zachodniopomorskie ma 'parent' 0 czyli głowne(województwo), a
> Człopa, Mirosławiec 'parent' 1 czyli gmina
Tu tak samo.
> +++
>
> POJAZD
> id_pojazdu int
> ID_RODZAJU
> ID_MARKI
> typ varchar(30) (sedan,kombi...)
> cena int
> cena_do_negocjacji tinyint(1) (0 lub 1 - tak/nie)
> rok_prod int(4)
> pojemnosc_silnika int(4)
> moc_silnika int(3)
> przebieg_km int(6)
> skrzynia varchar(15) (automat,normalna)
> paliwo varchar(15) (diesel,benzyna,benzyna+lpg)
> ile_drzwi tinyint(1) (2,3,4,5)
> kolor varchar(30)
> kolor_metalic tinyint(1) (0 lub 1 - tak/nie)
> data_1_rej varchar(7)
> waznosc_przegladu varchar(7)
> waznosc_ubezpieczenia varchar(7)
> opis pojazdu text
> imie_nazwisko_sprzedajacego varchar(70)
> prywatnie_komis_dealer tinyint(1) (1,2,3)
> ID_GMINY
> miasto varchar(30)
> email varchar(70)
> telefon varchar(10)
> telefon2 varchar(10)
>
> INNA TABELA?????
>
> auto posiada:
> abs tinyint(1) (0 lub 1 - tak/nie)
> alarm tinyint(1) (0 lub 1 - tak/nie)
> alufelgi tinyint(1) (0 lub 1 - tak/nie)
> .......
> itd.
> informacje_dodatkowe:
> homologacja_na_ciezarowe tinyint(1) (0 lub 1 - tak/nie)
> bezwypadkowy tinyint(1) (0 lub 1 - tak/nie)
> garazowany tinyint(1) (0 lub 1 - tak/nie)
> .......
> itd.
Nie ma potrzeby tego rozbijać.
> +++
>
> ZDJECIA
> id_foto int
> id_pojazdu int
> nazwa_pliku varchar(12)
>
> Biorąc pod uwagę, że mogą to być tylko pliki .jpg to chyba nawet nie musi
> być 'nazwa_pliku' bo nazwę pliku można tworzyć wg id_foto dodając tylko do
> niego .jpg
> ++++++++++++++++++++++++++
>
> Czy taki układ tabel jest optymalny? Nie wiem czy w namiary nie lepiej jest
> zmienic gminy na powiaty bo gmin jest ponad 2000 a powiatów 300.
Dla bazy to nie ma znaczenia.
> Może w
> ogole zrezygnować z tabeli namiary i obok info o miejscowości, którą wpisuje
> user dodać też selecta do dodania województwa, które też będzie wpisywane w
> tabeli POJAZD?
Z osobnej tabeli nie rezygnuj, bo potem będziesz miał Mirosławiec, Miroslawiec, Milosrawiec, itp.
> Co zrobić z informacjami o wyposażeniu auta bo żeby każda opcja miała swoje
> pole 0 lub 1 to jest raczej poroniony pomysł, nawet w osobnej tabeli? Może
> lepiej w tabeli POJAZD, ale dać pole ENUM tylko czy to pozwoli szybko
> wyświetlic zapytanie o pojazdy z np. alufelgami?
> Czy idąc dalej można zamienić pole tinyint(1) na pole SET i czy to nie
> opóżni wyszukiwania?
Czym Ty się przejmujesz? Musisz się zmieścić na dysku 10MB?
--
P.M.
albert - 13-09-2007 00:04
>> RODZAJE
>> ID_RODZAJU int(4)
>> rodzaj varchar(20)
>>
>> Gdzie 'rodzaj' to samochody osobowe, samochody cięzarowe, samochody
>> uszkodzone, starocie.....
>> +++
>>
>> MARKI
>> ID_MARKI int(6)
>> marka varchar(20)
>> parent tinyint(1) (0 lub 1)
>>
>> Gdzie 'marka' to AUDI,80,90,100,200....z tym że AUDI ma 'parent' 0 czyli
>> rodzaj auta, a 80,90,100... 'parent' 1 czyli model auta
>
> Przesadziłeś, rozbij to na dwie tabele.
czyli lepiej:
CREATE TABLE marki (
id INT NOT NULL PRIMARY KEY,
nazwa VARCHAR(100)
);
CREATE TABLE modele (
id INT NOT NULL PRIMARY KEY auto_increment,
markaid INT NOT NULL,
nazwa VARCHAR(100)
);
myslalem, ze jedna tabela wystarczy czy taki dwutabelowy nie bedzie sprawial
przy wyszukiwaniu? i czy tabela modele nie jest 'nadmiarowa'? :)
>> NAMIARY
>> ID_GMINY int(6)
>> woj_gmina varchar(40)
>> parent tinyint(1) (0 lub 1)
>>
>> Gdzie 'woj_gmina' to
>> Zachodniopomorskie,Świnoujście,Człopa,Mirosławiec. ...z
>> tym , że Zachodniopomorskie ma 'parent' 0 czyli głowne(województwo), a
>> Człopa, Mirosławiec 'parent' 1 czyli gmina
>
> Tu tak samo.
ok jedna to wojewodztwo, ale druga gminy(ponad2000) czy lepiej mniej
obszerna powiaty (ponad300) ? chodzi o to, ze na stronie jak bedzie select
to troszke dlugi w przypadku gmin bedzie...
>> POJAZD
>> id_pojazdu int
>> ID_RODZAJU
>> ID_MARKI
>> typ varchar(30) (sedan,kombi...)
.....
>> miasto varchar(30)
>> email varchar(70)
>> telefon varchar(10)
>> telefon2 varchar(10)
>>
>> INNA TABELA?????
>>
>> auto posiada:
>> abs tinyint(1) (0 lub 1 - tak/nie)
>> alarm tinyint(1) (0 lub 1 - tak/nie)
>> alufelgi tinyint(1) (0 lub 1 - tak/nie)
>> .......
>> itd.
>> informacje_dodatkowe:
>> homologacja_na_ciezarowe tinyint(1) (0 lub 1 - tak/nie)
>> bezwypadkowy tinyint(1) (0 lub 1 - tak/nie)
>> garazowany tinyint(1) (0 lub 1 - tak/nie)
>> .......
>> itd.
>
> Nie ma potrzeby tego rozbijać.
no ok, ale 'auto posiada' i 'informacje dodatkowe' to w sumie bylo by
kilkadziesiat dodatkowych pol.... ma to sens czy nie lepiej sprawe zalatwic
przez ENUM? wtedy mamy zajete dwa pola. nie chodzi o miejsce na dysku tylko
o przejrzystosc i szybsze wyszukiwanie po okreslonych kryteriach....
nie wiem tylko slyszalem, ze w ENUM moga byc problemy z wyszykiwaniem po
jedenj z warosci jakie zawiera...
albert - 13-09-2007 00:04
a i jeszcze przy okazji jedno, szukam, ale nim oge wygoglowac bazki
samochodow marka/typ... wiem moge sobie wklepac, ale po co wywazac otwarte
drzwi? :)
=?ISO-8859-2?Q?Pawe=B3_Matejski?= - 13-09-2007 00:04
albert wrote:
> czyli lepiej:
>
> CREATE TABLE marki (
> id INT NOT NULL PRIMARY KEY,
> nazwa VARCHAR(100)
> );
>
> CREATE TABLE modele (
> id INT NOT NULL PRIMARY KEY auto_increment,
> markaid INT NOT NULL,
> nazwa VARCHAR(100)
> );
>
> myslalem, ze jedna tabela wystarczy czy taki dwutabelowy nie bedzie sprawial
> przy wyszukiwaniu? i czy tabela modele nie jest 'nadmiarowa'? :)
Nie jest, a do tego łatwiej będzie Ci zapytania pisać i do tego nikt nie będzie
musiał sie zastanawiać co autor miał na myśli jak to projektował.
>>> NAMIARY
>>> ID_GMINY int(6)
>>> woj_gmina varchar(40)
>>> parent tinyint(1) (0 lub 1)
>>>
>>> Gdzie 'woj_gmina' to
>>> Zachodniopomorskie,Świnoujście,Człopa,Mirosławiec. ...z
>>> tym , że Zachodniopomorskie ma 'parent' 0 czyli głowne(województwo), a
>>> Człopa, Mirosławiec 'parent' 1 czyli gmina
>> Tu tak samo.
>
> ok jedna to wojewodztwo, ale druga gminy(ponad2000) czy lepiej mniej
> obszerna powiaty (ponad300) ? chodzi o to, ze na stronie jak bedzie select
> to troszke dlugi w przypadku gmin bedzie...
To juz nie problem bazy danych. Ale możesz to rozbić na województwa, powiaty, gminy.
Wtedy nie będziesz miał zbyt dużo danych na raz.
> no ok, ale 'auto posiada' i 'informacje dodatkowe' to w sumie bylo by
> kilkadziesiat dodatkowych pol.... ma to sens czy nie lepiej sprawe zalatwic
> przez ENUM? wtedy mamy zajete dwa pola. nie chodzi o miejsce na dysku tylko
> o przejrzystosc i szybsze wyszukiwanie po okreslonych kryteriach....
> nie wiem tylko slyszalem, ze w ENUM moga byc problemy z wyszykiwaniem po
> jedenj z warosci jakie zawiera...
Nie znam się za bardzo na ENUM, nie miałem przyjemności skorzystać. Ale podejrzewam, że natkniesz
się na jeden problem. ENUM musi miec chyba zdefiniowane wszystkie wartości przy zakładaniu kolumny.
Więc możesz mieć mały problem gdy pojawi cie jakaś cecha której nie przewidziałeś. Lepiej zrobić
to po bazdonowemu:
CECHY:
id
nazwa
POJAZDY_CECHY
id_pojazdu
id_cechy
--
P.M.
albert - 13-09-2007 00:04
Użytkownik "Paweł Matejski" <madej@spam.madej.pl.eu.org> napisał w
wiadomości news:fc8q3e$c04$1@inews.gazeta.pl...
> albert wrote:
>> czyli lepiej:
>>
>> CREATE TABLE marki (
>> id INT NOT NULL PRIMARY KEY,
>> nazwa VARCHAR(100)
>>
>> CREATE TABLE modele (
>> id INT NOT NULL PRIMARY KEY auto_increment,
>> markaid INT NOT NULL,
>> nazwa VARCHAR(100)
>> myslalem, ze jedna tabela wystarczy czy taki dwutabelowy nie bedzie
>> sprawial
>> przy wyszukiwaniu? i czy tabela modele nie jest 'nadmiarowa'? :)
>
> Nie jest, a do tego łatwiej będzie Ci zapytania pisać i do tego nikt nie
> będzie
> musiał sie zastanawiać co autor miał na myśli jak to projektował.
pytam tak dociekliwie bo ostanio jak pytalem o podobna baze to wlasnie
fachowcy z tej strony radzili taki model 'jednokolumnowy', ale jak rozumiem
trudno tu bedzie o konsensus, zwlaszcza ze odpowiedzi udziela jeden
fachowiec :)
>>>> NAMIARY
>>>> ID_GMINY int(6)
>>>> woj_gmina varchar(40)
>>>> parent tinyint(1) (0 lub 1)
>>>>
>>>> Gdzie 'woj_gmina' to
>>>> Zachodniopomorskie,Świnoujście,Człopa,Mirosławiec. ...z
>>>> tym , że Zachodniopomorskie ma 'parent' 0 czyli głowne(województwo), a
>>>> Człopa, Mirosławiec 'parent' 1 czyli gmina
>>> Tu tak samo.
>>
>> ok jedna to wojewodztwo, ale druga gminy(ponad2000) czy lepiej mniej
>> obszerna powiaty (ponad300) ? chodzi o to, ze na stronie jak bedzie
>> select
>> to troszke dlugi w przypadku gmin bedzie...
>
> To juz nie problem bazy danych. Ale możesz to rozbić na województwa,
> powiaty, gminy.
> Wtedy nie będziesz miał zbyt dużo danych na raz.
a moze mi poradzic jak ma ktos kto juz taka bazke posiada?
>> no ok, ale 'auto posiada' i 'informacje dodatkowe' to w sumie bylo by
>> kilkadziesiat dodatkowych pol.... ma to sens czy nie lepiej sprawe
>> zalatwic
>> przez ENUM? wtedy mamy zajete dwa pola. nie chodzi o miejsce na dysku
>> tylko
>> o przejrzystosc i szybsze wyszukiwanie po okreslonych kryteriach....
>> nie wiem tylko slyszalem, ze w ENUM moga byc problemy z wyszykiwaniem po
>> jedenj z warosci jakie zawiera...
>
> Nie znam się za bardzo na ENUM, nie miałem przyjemności skorzystać. Ale
> podejrzewam, że natkniesz
> się na jeden problem. ENUM musi miec chyba zdefiniowane wszystkie wartości
> przy zakładaniu kolumny.
> Więc możesz mieć mały problem gdy pojawi cie jakaś cecha której nie
> przewidziałeś. Lepiej zrobić
> to po bazdonowemu:
>
> CECHY:
> id
> nazwa
>
> POJAZDY_CECHY
> id_pojazdu
> id_cechy
czyli kolejne dwie tabele i mi wydaje sie, ze to jest najlepsze rozwiazanie
to z ENUM tem mi sie nie podobalo nie mowiac o mnozeniu dsziesiatek pol
wartosciami int(1) z 0 lub jedynka.....
dzieki za wszystkie odpowiedzi, szkoda, ze wiecej nikt sie nie odezwal
(chyba, ze inni w 100% podzielaja Twoje poglady)
a co z bazka modeli/typow aut, slyszal ktos gdzie znalezc ?
=?ISO-8859-2?Q?Pawe=B3_Matejski?= - 13-09-2007 00:04
albert wrote:
> Użytkownik "Paweł Matejski" <madej@spam.madej.pl.eu.org> napisał w
> wiadomości news:fc8q3e$c04$1@inews.gazeta.pl...
>> albert wrote:
>>> czyli lepiej:
>>>
>>> CREATE TABLE marki (
>>> id INT NOT NULL PRIMARY KEY,
>>> nazwa VARCHAR(100)
>>>
>>> CREATE TABLE modele (
>>> id INT NOT NULL PRIMARY KEY auto_increment,
>>> markaid INT NOT NULL,
>>> nazwa VARCHAR(100)
>>> myslalem, ze jedna tabela wystarczy czy taki dwutabelowy nie bedzie
>>> sprawial
>>> przy wyszukiwaniu? i czy tabela modele nie jest 'nadmiarowa'? :)
>> Nie jest, a do tego łatwiej będzie Ci zapytania pisać i do tego nikt nie
>> będzie
>> musiał sie zastanawiać co autor miał na myśli jak to projektował.
>
> pytam tak dociekliwie bo ostanio jak pytalem o podobna baze to wlasnie
> fachowcy z tej strony radzili taki model 'jednokolumnowy', ale jak rozumiem
> trudno tu bedzie o konsensus, zwlaszcza ze odpowiedzi udziela jeden
> fachowiec :)
No tu model drzewiasty nie pasuje. Zresztą dobrym wyznacznikiem jest to, że
nie znalazłeś jednej ogólnej nazwy na to. :) Ale najważniejsze jest to, czy
ta drzewiastość coś Ci ułatwi, czy tylko będzie utrudniać (np. modelowy przykład
z kategoriami, gdzie możesz robić stronę wyświetlającą listę podkategrii danej
kategorii - będzie wyświetlała tak samo listę, niezależnie od poziomu na którym
jest). Jak bardzo chcesz, to możesz się zastanowić, czy tak nie zrobić dla
województw,powiatów, gmin (dla 3 poziomów już warto się zastanowić ;) ).
--
P.M.
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
[mysql] =?ISO-8859-2?Q?Za=E6mienie=2E=2E=2E_jak_wy=B6wietli=E6?==?ISO-8859-2?Q?=2E=2E=2E?=
[mysql] =?ISO-8859-2?Q?wielko=B6=E6_bazy_a_stabilno=B6=E6=2C?==?ISO-8859-2?Q?_podzia=B3_du=BFej_bazy_a_powi=B1zania_tabel?=
[MySQL] =?ISO-8859-2?Q?Wy=B6wietlenie_kolejnej_pozycji=2C_?==?ISO-8859-2?Q?jak=B1_mia=B3by_dany_rekord=2C_gdybym_czyta=B3 _?==?ISO-8859-2?Q?wg_konkretnych_kryteri=F3w=2E_Da_si=EA_=3F?=
[mysql 4.0.x] przenoszenie kolum =?ISO-8859-2?Q?mi=EAdzy_bazam?==?ISO-8859-2?Q?i_cd_=2E=2E=2E_?=
[MySQL] =?ISO-8859-2?Q?z=B3=B1czenie_tabeli_u=BFytkownik_i?==?ISO-8859-2?Q?_zdj=EAcia_z_wyborem_zdj=EAcia_domy=B6lnego?=
[MySQL] Jak =?ISO-8859-2?Q?wpisa=E6_do_tabeli_pozycje_dl?==?ISO-8859-2?Q?a_wierszy_gdybym_te_wiersze_wybiera=B3_w_ok?== ?ISO-8859-2?Q?re=B6lonej_kolejno=B6ci_=3F?=
Gdzie MySQL 4.1, a gdzie 5.0?
[MySQL 4.0...4.1] zabezpieczenie przed =?ISO-8859-2?Q?jednoczesn?==?ISO-8859-2?Q?=B1_edycj=B1?=
[MS SQL] "set names" (mySQL) w MS SQL
[mysql 5.x] jak =?ISO-8859-2?Q?zrealizowa=E6_zapytanie=3F_cz?==?ISO-8859-2?Q?yli_podzapytanie_i_wi=EAcej_ni=BF_jeden_rz=B1? ==?ISO-8859-2?Q?d_wynik=F3w?=
zanotowane.pldoc.pisz.plpdf.pisz.plshanti.opx.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
