Dodanie wiersza do widoku w bazie danych, nie pogardzę rozwiązaniem alternatywnym ;) Opcje

[batman]

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.

[nevt]

@nevt
Nie zrozumiałeś mojego problemu.

przeciez napisałem wyraźnie:

nie bardzo rozumiem problem...

grunt że obaj rozumiemy że nie możemy nawzajem się zrozumieć (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

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.