🚀 go-pugleaf

Użytkownik "mk" <mk@nospam.com> napisał w wiadomości grup 
dyskusyjnych:hfl659$raf$1@atlantis.news.neostrada.pl...
> Witam,

Witam

> Korzystam z dostępu do danych w MSSQL za pomocą Linq. Mam tam tabelę 
> powiedzmy "województwa", która ma dwie kolumny Guid i Name i przechowuje 
> nazwy województw (16 rekordów).
>
> Nsatępnie w kodzie, żeby rozróżnić które województwo zostało wybrane robię 
> coś takiego:
>
> string strWojewodztwo = (tu jakies query);
>
> switch(strWojewodztwo)
> {
>    case "mazowieckie":
> //rob cos
> break;
>    case "malopolskie":
> //rob cos
> break;
>    case "dolnoslaskie":
> //rob cos
> break;
>    case "slaskie":
> //rob cos
> break;
>    .....
> }
>
> Wydaje mi się że nie jest to najlepszy pomysł żeby switch() orientował się 
> na podstawie wartości typu string. O wiele lepiej było by zrobić

Stringi w C# są przechowywane w "magazynie stringów", zmienna przechowuje 
tylko id z "magazynu".
Więc porównywanie stringów nie jest kosztowne, faktycznie jest to porównanie 
dwóch id. Ja bym zostawił na stringach tego switcha.


> public enum BinaryDataType
> {
>    mazowieckie,
>    malopolskie,
>    doloslaskie,
>    slaskie,
>    ....
> }
>
> Tylko jak dane z takiego enum'a sprząc z daymi w bazie?
> Chodzi o to, że w jakiejs innej tabeli zamiast Guid wojewodztwa musialbym 
> przechowywac numer zgodny z tym w enumie.

Problemy przy zmianie enuma lub bazy. Bym raczej unikał.

> P.S.
> Wojewodztwa to tylko przyklad. W rzeczywistosci bede przetrzymywal inne 
> wartosci.
>
> __________ Informacja programu ESET Smart Security, wersja bazy sygnatur 
> wirusow 4671 (20091208) __________
>
> Wiadomosc zostala sprawdzona przez program ESET Smart Security.
>
> http://www.eset.pl lub http://www.eset.com
>
> 

__________ Informacja programu ESET Smart Security, wersja bazy sygnatur wirusow 4671 (20091208) __________

Wiadomosc zostala sprawdzona przez program ESET Smart Security.

http://www.eset.pl lub http://www.eset.com 

Użytkownik "mk" <mk@nospam.com> napisał w wiadomości news:hfl659$raf$1@atlantis.news.neostrada.pl...
> Wydaje mi się że nie jest to najlepszy pomysł żeby switch() orientował 
> się na podstawie wartości typu string. O wiele lepiej było by zrobić

o wiele lepiej i bezpieczniej województwa przechowywać w formacie liczbowym (który też do czegoś poza identyfikacją może się przydać) i to najlepiej nie wymyslonym przez siebie tylko jakimś, który jest uznanym standardem, np. w tym przypadku TERYT: 02 dolnośląskie, 04 kujawsko-pomorskie, ... , 32 zachodniopomorskie.

http://www.stat.gov.pl/broker/access/index.jspa
http://pl.wikipedia.org/wiki/TERYT
-- 
td

> uznanym standardem, np. w tym przypadku TERYT: 02 dolnośląskie, 04
> kujawsko-pomorskie, ... , 32 zachodniopomorskie.

A nieparzyste gdzie im wcięło? Reserved?


-- 
Azarien

Użytkownik "Wiktor S." <wswiktor&poczta,fm@no.spam> napisał w wiadomości news:hfo408$s8j$1@news.onet.pl...
> A nieparzyste gdzie im wcięło? Reserved?

a to już pytanie do GUS albo ustawodawcy :)
-- 
td

>
> Stringi w C# są przechowywane w "magazynie stringów", zmienna  
> przechowuje tylko id z "magazynu".
> Więc porównywanie stringów nie jest kosztowne, faktycznie jest to  
> porównanie dwóch id. Ja bym zostawił na stringach tego switcha.
>
Nie chodzi o wydajność tylko poprawne programowanie, czytelność kodu,  
możliwość uniknięcia błędów.
Przecież to nie będzie miało żadnego wpływu na wydajność aplikacji! Chyba,  
że miliony razy w jakiejś
pętli by to porównywał. A wtedy akurat porównanie stringów nie byłoby  
dobre.

Skoro porównuje się na podstawie "id", to dlaczego są różnice w czasach  
porównania przy użyciu
==, equals, string.compare (z różnymi parametrami)?

>
>> public enum BinaryDataType
>> {
>>    mazowieckie,
>>    malopolskie,
>>    doloslaskie,
>>    slaskie,
>>    ....
>> }
>>
>> Tylko jak dane z takiego enum'a sprząc z daymi w bazie?
>> Chodzi o to, że w jakiejs innej tabeli zamiast Guid wojewodztwa  
>> musialbym przechowywac numer zgodny z tym w enumie.
>
> Problemy przy zmianie enuma lub bazy. Bym raczej unikał.

Jak są stringi to również masz problem jak zmienisz bazę danych.


Możesz trzymać stringi a potem zrobić tak.

string wojewodztwo = WyciagnijZBazy();

Wojewodztwo w = (Wojewodztwo)Enum.Parse(typeof(Wojewodztwo), wojewodztwo);

On 10 Gru, 22:00, 3P <nos...@serwer.pl> wrote:
> > Stringi w C# s przechowywane w "magazynie string w", zmienna  
> > przechowuje tylko id z "magazynu".
> > Wi c por wnywanie string w nie jest kosztowne, faktycznie jest to  
> > por wnanie dw ch id. Ja bym zostawi na stringach tego switcha.
>
> Nie chodzi o wydajno tylko poprawne programowanie, czytelno kodu,  
> mo liwo unikni cia b d w.
> Przecie to nie b dzie mia o adnego wp ywu na wydajno aplikacji! Chyba,  
> e miliony razy w jakiej
> p tli by to por wnywa . A wtedy akurat por wnanie string w nie by oby  
> dobre.
>
> Skoro por wnuje si na podstawie "id", to dlaczego s r nice w czasach  
> por wnania przy u yciu
> ==, equals, string.compare (z r nymi parametrami)?
>
>
>
> >> public enum BinaryDataType
> >> {
> >>    mazowieckie,
> >>    malopolskie,
> >>    doloslaskie,
> >>    slaskie,
> >>    ....
> >> }
>
> >> Tylko jak dane z takiego enum'a sprz c z daymi w bazie?
> >> Chodzi o to, e w jakiejs innej tabeli zamiast Guid wojewodztwa  
> >> musialbym przechowywac numer zgodny z tym w enumie.
>
> > Problemy przy zmianie enuma lub bazy. Bym raczej unika .
>
> Jak s stringi to r wnie masz problem jak zmienisz baz danych.
>
> Mo esz trzyma stringi a potem zrobi tak.
>
> string wojewodztwo = WyciagnijZBazy();
>
> Wojewodztwo w = (Wojewodztwo)Enum.Parse(typeof(Wojewodztwo), wojewodztwo);

Można zrobić tworzenie kodu enuma na podstawie tabeli w bazie danych.
Wtedy po przekompilowaniu będziesz miał dostęp do nazwy województwa a
po rzutowaniu na int jego id
Wadą jest to że trzeba się trzymać schematu że jeżeli coś dodam do tej
tabeli to musze odpalić zrzucanie do enum i przekompilować