🚀 go-pugleaf

SELECT Tabela.imie+','+Tabela.Nazwisko AS Nazwa
FROM Tabela

"Depesz" <dep...@poczta.onet.pl> wrote in message
news:c60dca$g84$1@opal.icpnet.pl...
> Jak polaczyc dwa pola  pobierane z bazy danych  np imie i nazwisko, aby w
> DataGridzie wyswietlaly sie w jednej kolumnie?
>
>

Adam wrote:
> SELECT Tabela.imie+','+Tabela.Nazwisko AS Nazwa
> FROM Tabela
[...]

Witam!

Wygląda na to, że można także po stronie klienta skoro dane są i tak
ładowane DataSet-u. Jest coś takiego jak DataColumn.Expression. Poza tym
pewno można by modyfikować kolumnę z kodu, która nie jest przechowywana w
tabeli.

Z polami obliczeniowymi (po stronie aplikacji) był zawsze problem ponieważ
trudno było z tym później cokolwiek wykonać. Takie funkcje jak sortowanie,
indeksowanie, wyszukiwanie, filtrowanie albo odwoływały się do serwera lub
engina bazy danych. Dla nich zawartość tylko kolumn była niewidoczna. Albo
obliczanie zawartości kolumn następowało dopiero po filtrowaniu. Było
jeszcze bardziej przykre jeśli trzeba była zrobić w aplikacji
filtrowanie/sortowanie po dowolnej kolumny. Np. po kliknięciu. A tu
niespodzianka, inną kolumnę się wyświetla, a po innej sortuje. Tak
przynajmniej było w Delphi i myślę, że te problemy są dosyć uniwersalne.

Ale ponieważ w ADO.NET jest DataSet wydaje mi się, że można sobie pozwolić
na wiele. Miejmy nadzieje, że możliwości dostępne pod stronie aplikacji są
wykraczające do wygodnej obróbki takich danych.

Ponad to wydaje mi się, że w wielu przypadkach jest i tak sensowne
przechowywanie w bazie danych tych samych danych podzielonych jak i
połączony. Uzasadniał bym to praktycznie, jak i ze względu na uproszczenie
używania danych. Praktycznie ponieważ, można dać kontrolkę użytkownikowi nad
łączeniem. Np. jak pełen adres jest łączony z nazwy miejscowości i adresu.
Program może podpowiadać przecinek ale nie zawsze musi to być pożądane.
Ponadto sumaryczna długość pola może być mniejsza. Praktycznie nie
wykorzysta się dwóch polach pełnej ich długości jednocześnie, w razie czego
użytkownik dokona skrótu.

Inne rozwiązanie można nie łączyć takich danych i próbować wyświetlać,
szukać, drukować wszystko osobno. Jako osobne kolumny. Czasem szukanie
osobno jest bardzo wygodnie. Np. łatwo można grupować dane miastami. Ale do
wyświetlania czy drukowania może okazać się to kłopotliwe. Takie tabela z
wieloma kolumnami zajmuje wiele miejsca. Łącząc dane lepiej wykorzystujemy
przestrzeń na ekranie / wdruku.

Także wydaje mi się wcale nie trywialnym problem w wielu przypadkach.
Przechowywać wszystko razem czy osobno. Być może właściwa odpowiedź brzmi, i
tak i tak. Chyba, że przypadek połączenia pól jest naprawdę rzadko
stosowany. Np. kod pocztowy w adresie występuje tylko na jakiś wydrukach
VAT, fakturach. Nikt nie chciał by szukać po czymś takim. W wielu widokach
taka informacja jest zbędna. Oczywiście rozdzielenie danych w czasie
wprowadzania dyscyplinuje użytkownika, zbytnie usztywnienie natomiast
sprawia problemy. Np. wydaje mi się, że nie ma sensu założyć, że kod
pocztowy ma określoną maskę. W innych krajach są inne kody pocztowy, może są
wyjątki o reguły albo coś może się zmienić. Natomiast ma sens kontrola i
ostrzeganie o błędach sum kontrolnych, jeśli takie występują.

P.S. Ciekawe czy komuś przyda się to co wyskrobałem.

-- 
Pozdrawiam,
Marek Janaszewski
[ j_m...@gazeta.pl ]