Mam pewien nietypowy problem. W bazie danych znajdują się dwie tabele: tabuser i tabprofile. W tabeli tabprofile znajduje się pole iduser, które jest kluczem obcym. Używając join-a stworzyłem widok, który ułatwi mi pobieranie danych o użytkowniku. I rzeczywiście, jest to wygodne rozwiązanie w przypadku pobierania danych. Jednak w przypadku usuwania lub dodawania danych nie jest już tak różowo - niepoprawne zapytanie i błąd.
Rozwiązałem ten problem w taki sposób, że klasa Account agreguje klasy User i Profile, które są odpowiedzialne za operacje na danych w odpowiednich tabelach. Rozwiązanie to sprawdza się w praktyce, jednak moim zdaniem jest nieco przekombinowane.
Macie jakieś pomysły na rozwiązanie tego problemu? Połączenie tabel w jedną nie wchodzi w grę, podobnie jak funkcje trigger.

Może nie zrozumiałem problemu ale chyba widoków nie można modyfikować. Widoki są tylko pewnym ujęciem innych fizycznych danych. Wszelkie operacje powinny być dokonywane na tabelach źródłowych.

Można edytować dane w widoku (update działa, inserta nie sprawdzałem), pod warunkiem, że wykonuje się operacje na jednej ze złączonych tabel.

edit
Nie twierdzę, że jest to idealne rozwiązanie. Szukam rozwiązania tego problemu, ponieważ za długo już nad tym siedzę i zaczynam widzieć robaczki przed oczami

no to człowiek nauczył się czegoś nowego...

1. jaka baza? (google mowi ze da sie zrobic insert do kolumn z tylko jednej tabeli!)
2. bez triggerow to ciezko (bo z tego co wiem - nie uzywalem - to wlasnie nimi sie to zalatwia)

Kurcze nie mam teraz pod ręką booka, ale wydawało mi się, że (przynajmniej w PostgreSQL) jest tak, że jeśli widok operuje na jednej tabeli to można do niego wrzucać dane jak do zwykłej tabeli pod warunkiem, że zawiera wszystkie wymagane pola z tabeli źródłowej. Osobiście ciężko mi sobie wyobrazić INSERT do widoku będącego złączeniem kilku tabel...

1. Baza dowolna. Rozwiązanie musi być w pełni przenaszalne (oczywiście w granicach rozsądku - PostgreSQL, MySQL, DB2, Oracle, MSSQL, Sybase).
2. W związku z powyższym nie może być to trigger ani żadna funkcja

nie bardzo rozumiem problem... każda baza, którą wymieniłeś jest relacyjną bazą danych. relacyjne bazy danych w swojej istocie zawierają mechanizmy służące do rozwiązywania tego typu problemów. wszystko sprowadza się do ustalenia odpowiednich reguł dla relacji. z reguły dostępne są trzy możliwości:
1. baza nic nie robi
2. baza sprawdza integralność danych (to znaczy czy dla klucza obcego istnieje odpowiedni klucz podstawowy w powiązanej tabeli) - w przypadku naruszenia integralności nie pozwala na zmianę danych i wyrzuca błąd
3. baza kaskadowo aktualizuje / usuwa rekordy w tabelach powiązanych relacją (czyli dokładni to co potrzebujesz)

nie trzeba nic kombinować, obchodzić ani poprawiać, te mechanizmy są wbudowane w każdą relacyjną bazę danych ...

@nevt
Nie zrozumiałeś mojego problemu.
1. Mam dwie tabele: tabuser i tabprofile.
2. Na ich podstawie utworzyłem widok. Ma on za zadanie usprawnić pobieranie danych o konkretnym koncie (czyli złączeniu tabuser i tabprofile).
3. Klasa Account zawiera instancje klas User i Profile do edycji danych w odpowiadających im tabelach.

Moim problemem jest to, że nie mogę wykonywać operacji bezpośrednio na widoku. Muszę je dokonać osobno dla każdej tabeli. Szukam rozwiązania, które mi to umożliwi. Nie jest to aż tak duży problem, jednak im dłużej nad tym siedzę, tym większy mam w głowie chaos

A teraz założenia:
1. Rozwiązanie musi być w pełni przenaszalne - dlatego odpadają triggery, itp.
2. Nie można połączyć tych tabel w jedną tabelę, ponieważ tabuser jest identyczne dla kilku różniących się od siebie serwisów, dzięki czemu można bez problemu synchronizować "bazę użytkowników". tabprofile odpowiada za specyficzne dla danego systemu wariacje konta użytkownika (nr telefonu, imię, nazwisko, adres, itd)
3. Nie upieram się na widok. Jeśli masz jakiś inny pomysł, to z chęcią go wysłucham.

przeciez napisałem wyraźnie:

grunt że obaj rozumiemy że nie możemy nawzajem się zrozumieć

a wracając do sedna sprawy. mając takie założenia odwróciłbym problem, teraz masz tak:
1. rozdzielasz zbiór danych na dwie tabele, po potrzebujesz synchronizować profile użytkowników między bazami (rzadko wykonywane operacje).
2. budujesz widok sklejający je w całość żeby z niego korzystać w aplikacji gdzie pod jednym ID potrzebne są ci wszystkie pola do swobodnej edycji (częste operacje).
3. widoki są różnie implementowane w różnych bazach, pojawia się problem przenoszalności.
4. w konsekwencji kończy sie na oddzielnych aktualizacjach każdej z tabel, co komplikuje kod i powoduje problem z utrzymaniem spójności danych.

jak ci sie widzi taka koncepcja:
1. wrzucasz wszystkie niezbędne dane do jednej tabeli
2. często wykonywane operacje wykonujesz na pojedynczej tabeli bez pośrednictwa widoków - wszystkie twoje problemy znikają ...
3. w zamian tworzysz widok zawierający wspólny dla wszystkich baz podzbiór pól (który teraz masz w pierwszej tabeli) z przeznaczeniem na synchronizacje profili.
4. ponieważ ten widok zawiera wyłącznie pola z jednej tabeli, możesz spokojnie na nim operować jak na zwykłej tabeli (pod warunkiem, że będzie zawierał klucz podstawowy i wszystkie wymagane pola które nie przyjmują wartości domyślnych przy insercie ...)

pozdrawiam.

1. Operacja wykonywana jest za każdym razem, gdy w jednym z serwisów zakładane jest nowe konto. Wówczas tabele tabuser są synchronizowane.
3. Każda baza danych posiada taki sam podstawowy mechanizm do tworzenia widoków.
4. Patrz punkt 1 - synchronizowana jest tylko tabela tabuser (w wyjątkowych sytuacjach może dojść do synchronizacji niektórych pól z tabprofile)


Pomysł bardzo fajny, jednak już go wałkowałem
3. Synchronizacja tylko niektórych pól nie jest najlepszym rozwiązaniem, ponieważ w różnych serwisach różne pola są wymagane. W jednym będzie to numer telefonu, w innym imię i nazwisko, w jeszcze innym wiek. A nie każdy system będzie posiadał te pola w bazie danych. Dodanie nowego serwisu będzie skutkowało tym, że skrypt do synchronizacji będzie musiał być przerabiany dla każdego nowego serwisu (a liczba serwisów jest ograniczona jedynie wyobraźnią klienta ).

Zastanawiałem się również nad stworzeniem tabeli tymczasowej, która pełniłaby rolę kontenera na dane z tabuser i tabprofile, jednak takie rozwiązanie stworzy dodatkowy problem z synchronizacją danych w obrębie jednej bazy danych.