Re: =?iso-8859-2?Q?Kodowanie_podstawowych_p=F3l_w_bazie?=
sg - 07-01-2007 00:10
Dnia 06-01-2007 o 18:31:58 <spam@spam.pl> napisał(a):
> Niestety brak mi większego doświadczenia, a potrzebuje podstawowych
> informacji ad. tego jak sie koduje standardowe atrybuty w bazach
> biznesowych i nie tylko:
>
> PESEL - 11 cyfr, czyli jako ciąg znaków, czy jako duza liczbe?
> z tego co zauważyłem to standardem jest chyba Varchar(11)
> NIP - 10 cyfr, ale forma nipu zawiera w sobie również 3 myślniki.
> Czy w bazie przechowujemy te 3 myslniki, czy nie?
> Podobnie jest z kodem pocztowym. Obiło mi sie o uszy, że się przechowuje
> bez myślników, a dodaje je sie jedynie przy wyświetlaniu. Choc gdzieś w
> necie widziałem właśnie: NIP varchar(13). Czyli jak w końcu?
>
NIP ma 2 postaci: 123-12-12-123 oraz 123-123-12-12 i nigdy nie wiesz czy
się nie zmieni... nie mówiąc o nipie europejskim i tym, że tak naprawdę
wszędzie używa się też nipu bez kresek.
Ja tam robię jako NIP varchar (50) i nie przejmuję się tym.
> Podobny problem jest również z numerem konta bankowego, numerem telefonu.
>
> REGON - tu mogą byc 7, 9 lub 14 cyfrowe numery, czyli Varchar(14) ?
>
varchar(50)
> "ADRES" - to sie rozbija na elementy(miasto, kod pocztowy, ulica, nr
> bloku,
> nr mieszkania) i traktuje jako osobne atrybuty w tabeli, tak? Czy może 1
> atrybut ADRES jakiegos typu Rekordowego T_ADRES?
>
to nie robi większej różnicy, ale za to kopiowanie jednego adresu na inny
może być łatwiejsze jak zrobisz to jako T_ADRES
>
> Jakie są "STANDARDOWO" przyjęte maksymalne długości pól takich jak:
> MIASTO, ULICA, IMIE, NAZWISKO, NAZWA_FIRMY, WWW, EMAIL, NR_TELEFONU,
> NR_KONTA_BANKOWEGO, itp.
>
takie jak chcesz, nie ma standardów
>
> Czy mógłby ktoś wspomóc linkiem, gdzie tego typu zagadnienia sa
> poruszone,
> czy podzielić sie własnymi doświadczeniami w tej kwestii.
> Albo jakiś przykład prostej wzorcowej bazy biznesowej.
>
jak dla mnie optymalizacja żeby robić varchar(13) przy nipie jest bez
sensu, a co jak zmieni się format nipu? Ja tam mam zawsze standardowo w
bazie napisy typu:
krótki_string = varchar (50)
średni_string = varchar (200)
długi_string = varchar (2000)
Artur Muszynski - 07-01-2007 00:11
=?iso-8859-2?Q?Re:_Kodowanie_podstawowych_p=F3l_w_bazie?=
sg wrote:
> jak dla mnie optymalizacja żeby robić varchar(13) przy nipie jest bez
> sensu, a co jak zmieni się format nipu? Ja tam mam zawsze standardowo
> w bazie napisy typu:
> krótki_string = varchar (50)
> średni_string = varchar (200)
> długi_string = varchar (2000)
Czy to jest optymalizacja, to nie wiem, ale na pewno pomaga w utrzymaniu
spójności danych. W posgresql można w ogóle pominąć długość pola i jest
spokój.
artur
sg - 07-01-2007 00:11
Dnia 06-01-2007 o 21:50:10 Artur Muszynski <arturm@union.wytnijto.com.pl>
napisał(a):
> sg wrote:
>> jak dla mnie optymalizacja żeby robić varchar(13) przy nipie jest bez
>> sensu, a co jak zmieni się format nipu? Ja tam mam zawsze standardowo
>> w bazie napisy typu:
>> krótki_string = varchar (50)
>> średni_string = varchar (200)
>> długi_string = varchar (2000)
>
> Czy to jest optymalizacja, to nie wiem, ale na pewno pomaga w utrzymaniu
> spójności danych. W posgresql można w ogóle pominąć długość pola i jest
> spokój.
>
> artur
>
ale nie ma czegoś takiego jak optymalizacja przy zmianie varchar(50) na
varchar(13)
Kamil - 07-01-2007 00:11
Dnia Sat, 06 Jan 2007 18:40:57 +0100, sg napisał(a):
> jak dla mnie optymalizacja żeby robić varchar(13) przy nipie jest bez
> sensu, a co jak zmieni się format nipu? Ja tam mam zawsze standardowo w
> bazie napisy typu:
> krótki_string = varchar (50)
> średni_string = varchar (200)
> długi_string = varchar (2000)
Będąc kiedyś na wykladzie z Inżynierii Oprogramowania, pamiętam jak mój
wykładowca poświęcił temu zagadnieniu troche czasu, tzn maksymalnej
długości pola "nazwisko", "miasta", itp w bazie danych.
Niestety nie podał gotowych wartości, a jedynie zwrócił uwage na problem.
Potrzebę takiego traktowania sprawy uzasadniał nie tyle optymalizacją, co
np. późniejszym wykorzystaniem tych danych w interfejsie użytkownika
(rozmiar komponentów na formatkach)
A ad. takich atrybutów jak NIP czy PESEL to maksymalna dlugość słuzy
również pewnej weryfikacji poprawności danych (utrzymaniu spójności
danych).
A zmiany w prawie, np. jeszcze dłuższy REGON, jak zwykł mówić ten sam
wykładowca są bardzo dobre dla informatyków, gdyż wtedy klient zwraca się
do nas o wniesienie poprawek w naszym działającym systemie, których my
oczywiście nie dokonujemy charytatywnie. ;)
--
Pozdrawiam
Kamil
Michal Jankowski - 07-01-2007 00:11
Kamil <spam@spam.pl> writes:
> Będąc kiedyś na wykladzie z Inżynierii Oprogramowania, pamiętam jak mój
> wykładowca poświęcił temu zagadnieniu troche czasu, tzn maksymalnej
> długości pola "nazwisko", "miasta", itp w bazie danych.
> Niestety nie podał gotowych wartości, a jedynie zwrócił uwage na problem.
> Potrzebę takiego traktowania sprawy uzasadniał nie tyle optymalizacją, co
> np. późniejszym wykorzystaniem tych danych w interfejsie użytkownika
> (rozmiar komponentów na formatkach)
Tekst w okienku mozna przewinąć... A dla szanującej się bazy danych
zadeklarowanie maksymalnego (lub nie) rozmiaru pola nijak nie wpływa
ani na wydajność, ani na zajętość dysku.
> A ad. takich atrybutów jak NIP czy PESEL to maksymalna dlugość słuzy
> również pewnej weryfikacji poprawności danych (utrzymaniu spójności
> danych).
To oczywiście jest jakiś powód - ale średnio się stosuje do adresów
czy nazwisk...
> A zmiany w prawie, np. jeszcze dłuższy REGON, jak zwykł mówić ten sam
> wykładowca są bardzo dobre dla informatyków, gdyż wtedy klient zwraca się
> do nas o wniesienie poprawek w naszym działającym systemie, których my
> oczywiście nie dokonujemy charytatywnie. ;)
No to jest powód wagi ogromnej. 8-)
MJ
sg - 07-01-2007 00:11
Dnia 06-01-2007 o 22:43:14 Kamil <spam@spam.pl> napisał(a):
> Dnia Sat, 06 Jan 2007 18:40:57 +0100, sg napisał(a):
>> jak dla mnie optymalizacja żeby robić varchar(13) przy nipie jest bez
>> sensu, a co jak zmieni się format nipu? Ja tam mam zawsze standardowo w
>> bazie napisy typu:
>> krótki_string = varchar (50)
>> średni_string = varchar (200)
>> długi_string = varchar (2000)
>
> Będąc kiedyś na wykladzie z Inżynierii Oprogramowania, pamiętam jak mój
> wykładowca poświęcił temu zagadnieniu troche czasu, tzn maksymalnej
> długości pola "nazwisko", "miasta", itp w bazie danych.
> Niestety nie podał gotowych wartości, a jedynie zwrócił uwage na problem.
> Potrzebę takiego traktowania sprawy uzasadniał nie tyle optymalizacją, co
> np. późniejszym wykorzystaniem tych danych w interfejsie użytkownika
> (rozmiar komponentów na formatkach)
>
W GUI to rzeczywiście można sobie takie rzeczy robić, ale mówiliśmy o
optymalizacji typu: czy varchar(13) czy może coś innego.
Przy varchar(13) i varchar(50) nie ma żadnej różnicy w ilości zajętego
miejsca, oczywiście możemy próbować optymalizować aż tak, że nie
varchar(13) ale char(13) i zyskamy cały 1B (albo nieco więcej) na
rekordzie. Niech to będą i 4 bajty na rekord... czyli to daje nam licząć,
że reszta danych firmy zajmie nawet 200B, całe 2% mniej... czyli na 1mln
rekordów, który zajmie jakieś 200MB, będziemy mieli aż o 4MB mniejszą
bazę... naprawdę taka optymalizacja nie ma sensu w porównaniu z tym co
będzie się działo przy wprowadzaniu zmian żeby przejść z char(13) na
char(15)
> A ad. takich atrybutów jak NIP czy PESEL to maksymalna dlugość słuzy
> również pewnej weryfikacji poprawności danych (utrzymaniu spójności
> danych).
>
bzdura, wystarczy, że przy zapisie sprawdzam czy numer jest w określonym
formacie, wyliczam sumę kontrolną dla NIPu, PESELa i REGONu i wtedy wiem,
że jest OK.
Sama długość nic nie daje.
> A zmiany w prawie, np. jeszcze dłuższy REGON, jak zwykł mówić ten sam
> wykładowca są bardzo dobre dla informatyków, gdyż wtedy klient zwraca się
> do nas o wniesienie poprawek w naszym działającym systemie, których my
> oczywiście nie dokonujemy charytatywnie. ;)
>
>
to prawda :)
Artur Muszynski - 07-01-2007 00:11
=?iso-8859-2?Q?Re:_Kodowanie_podstawowych_p=F3l_w_bazie?=
sg wrote:
> bzdura, wystarczy, że przy zapisie sprawdzam czy numer jest w
> określonym formacie, wyliczam sumę kontrolną dla NIPu, PESELa i
> REGONu i wtedy wiem, że jest OK.
> Sama długość nic nie daje.
Nie twierdzę, że nie masz po części racji, chociaż idąc twoim tropem
rozumowania należałoby w ogóle zrezygnować z ustawiania warunków poprawności
w bazie, bo robi się to po stronie aplikacji.
A teraz pytanie zasadnicze: Jeśli nic nie daje, to w takim razie dlaczego
dbms'y (poza w/w postgresem) uparcie zmuszają nas do jej podawania?
artur
sg - 07-01-2007 00:11
Dnia 07-01-2007 o 00:30:22 Artur Muszynski <arturm@union.wytnijto.com.pl>
napisał(a):
> sg wrote:
>> bzdura, wystarczy, że przy zapisie sprawdzam czy numer jest w
>> określonym formacie, wyliczam sumę kontrolną dla NIPu, PESELa i
>> REGONu i wtedy wiem, że jest OK.
>> Sama długość nic nie daje.
>
> Nie twierdzę, że nie masz po części racji, chociaż idąc twoim tropem
> rozumowania należałoby w ogóle zrezygnować z ustawiania warunków
> poprawności w bazie, bo robi się to po stronie aplikacji.
a gdzie ja to napisałem?
chodzi mi jedynie o to, że w przypadku chociażby NIPu samo ustawienie
długości na varchar(13) niewiele daje. Owszem, możesz wtedy wpisać tam
maksymalnie 13 znaków, ale to nie znaczy, że będzie tam wpisany poprawny
numer NIP.
> A teraz pytanie zasadnicze: Jeśli nic nie daje, to w takim razie
> dlaczego dbms'y (poza w/w postgresem) uparcie zmuszają nas do jej
> podawania?
>
bo taki masz typ danych?
bo taki jest standard?
bo wtedy wiadomo ile maksymalnie zajmie rekord?
Grzesiek G. - 09-01-2007 00:01
sg napisał(a):
> Dnia 06-01-2007 o 18:31:58 <spam@spam.pl> napisał(a):
>
>> Niestety brak mi większego doświadczenia, a potrzebuje podstawowych
>> informacji ad. tego jak sie koduje standardowe atrybuty w bazach
>> biznesowych i nie tylko:
>>
>> PESEL - 11 cyfr, czyli jako ciąg znaków, czy jako duza liczbe?
>> z tego co zauważyłem to standardem jest chyba Varchar(11)
>> NIP - 10 cyfr, ale forma nipu zawiera w sobie również 3 myślniki.
>> Czy w bazie przechowujemy te 3 myslniki, czy nie?
>> Podobnie jest z kodem pocztowym. Obiło mi sie o uszy, że się
>> przechowuje
>> bez myślników, a dodaje je sie jedynie przy wyświetlaniu. Choc gdzieś w
>> necie widziałem właśnie: NIP varchar(13). Czyli jak w końcu?
>>
>
> NIP ma 2 postaci: 123-12-12-123 oraz 123-123-12-12 i nigdy nie wiesz
> czy się nie zmieni... nie mówiąc o nipie europejskim i tym, że tak
> naprawdę wszędzie używa się też nipu bez kresek.
Nawet na fakturach drukujesz bez kresek?
Pozdrawiam
--
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!
Tadeusz Olszewski - 09-01-2007 00:01
Użytkownik "Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> napisał w
wiadomości news:ensr94$u39$1@opal.futuro.pl...
> sg napisał(a):
>> Dnia 06-01-2007 o 18:31:58 <spam@spam.pl> napisał(a):
>>
>>> Niestety brak mi większego doświadczenia, a potrzebuje podstawowych
>>> informacji ad. tego jak sie koduje standardowe atrybuty w bazach
>>> biznesowych i nie tylko:
>>>
>>> PESEL - 11 cyfr, czyli jako ciąg znaków, czy jako duza liczbe?
>>> z tego co zauważyłem to standardem jest chyba Varchar(11)
>>> NIP - 10 cyfr, ale forma nipu zawiera w sobie również 3 myślniki.
>>> Czy w bazie przechowujemy te 3 myslniki, czy nie?
>>> Podobnie jest z kodem pocztowym. Obiło mi sie o uszy, że się
>>> przechowuje
>>> bez myślników, a dodaje je sie jedynie przy wyświetlaniu. Choc gdzieś w
>>> necie widziałem właśnie: NIP varchar(13). Czyli jak w końcu?
>>>
>>
>> NIP ma 2 postaci: 123-12-12-123 oraz 123-123-12-12 i nigdy nie wiesz czy
>> się nie zmieni... nie mówiąc o nipie europejskim i tym, że tak naprawdę
>> wszędzie używa się też nipu bez kresek.
>
> Nawet na fakturach drukujesz bez kresek?
>
> Pozdrawiam
>
> --
> Grzegorz Gruza
Kolejność kresek w nipie nie ma żadnego znaczenia dla poprawności nipu.
Problem powstał ponieważ ktoś kiedyś (rok 1993) wykombinował, że osoby
fizyczne będą miały drukowany nip w formacie 999-999-99-99 natomiast osoby
prawne 999-99-99-999, było to ułatwienie dla urzędników i chyba tylko dla
nich. Jak zwykle w naszym kraju nabrało to mocy ustawowej. Możesz drukować
cyferki w nipie pogrupowane tak ja Ci to się spodoba, możeż drukować także
bez kresek. Nie jest to uregulowane w żadnych pprzepisach. A to co powie
pani w księgowości to już zupełnie inna historia.
Podrawiam
Tadeusz Olszewski
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
Wydajność baz danych w zależności od poziomu izolacji ANSI/ISO
Czy zna (obsługuje) ktoś program Iso Draw ?
strona plus baza w iso do utf-8
Konwesja znaków w dump'ie bazy danych - ISO -> utf-8 -> ISO -> utf-8
=?iso-8859-2?q?Co_oznacza_b=B3=B1d_Warning:_mysql=5Fconnect() _[function.mysql-connect]:_Can't_connect_to_local_MySQL_server_through_sock et_'/var/run/mysqld/mysqld.sock'_(2)_in?=
=?iso-8859-2?q?Informatyka,_Java,_EJB,_Ajax,_Spring=2E_Czy=BF by_to_koniec_=B6wiata,_czy_te=BF_nasze_uczelnie_b= EAd=B1_uczy=B3y_w_ko=F1cu!_czego_praktycznego_=2E= 2E=2E=2E?=
=?iso-8859-2?q?Ati_Mobility_Radeon_X300_W_Notebooku_Jak_Zwi=E Akszy=E6_Ilo=B6=E6_Grafiki_Poprzez_Wsp=F3=B3dziele nie_Z_Ramu=3F=3F=3F?=
=?ISO-8859-2?Q?=AFegnam_si=EA=2E=2E=2E?=
Manager =?ISO-8859-2?Q?font=F3w=2E=2E=2E?=
=?iso-8859-2?q?gdzie_naprawi=E6_tablet_wacoma=3F=3F=3F=3F?=
zanotowane.pldoc.pisz.plpdf.pisz.pllisinski.htw.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 |
|
