Siema,
Halp plox, chciałem taki case skonsultować z szanownym gremium.
Mamy dwie bazy pluszowych misiów. Każdy miś ma swój opis i fotę, + info gdzie aktualnie znajduje się na półce. Dane nie są trzymane identycznie, klucze danych są różne, etc.
Mamy dwie starsze panny które nie do końca sobie ufają i są zazdrosne o swoje misie, ale chciałyby żeby misie z kolekcji panny B znajdowały się w bazie panny A.
To co wykombinowałem: Robimy bazę przejściową. Do niej baza panny B wrzuca rekordy. W bazie robimy mapowanie, normalizację, zaciągamy fotę z linka na localhost, ew. procesujemy. Taki rekord czeka na usera który mu musi zrobić translację, sprawdzić, i klepnąć mu taga 'approved'.
Każdy misiek z tagiem 'approved' jest przepychany do bazy docelowej panny A. Jeżeli jest zmiana statusu pozycji na półce tego miśka, a jego status jest approved, to baza przejściowa już z automatu wypycha to info do bazy panny A.
Co myślita o tym?
On Thu, 20 Aug 2015, spin@hackerspace.pl wrote:
Robimy bazę przejściową. Do niej baza panny B wrzuca rekordy. W bazie robimy mapowanie, normalizację, zaciągamy fotę z linka na localhost, ew. procesujemy. Taki rekord czeka na usera który mu musi zrobić translację, sprawdzić, i klepnąć mu taga 'approved'.
Każdy misiek z tagiem 'approved' jest przepychany do bazy docelowej panny A. Jeżeli jest zmiana statusu pozycji na półce tego miśka, a jego status jest approved, to baza przejściowa już z automatu wypycha to info do bazy panny A.
Coś bliżej na temat technologii, której używasz? Zakładam jakiś SQL:
- Tabela M trzyma wszystkie miśki - Dostęp SELECT do tabeli M ma tylko naczelny niedźwiedź - Zdefiniowany jest widok MyDearBear na tabeli M z dodatkowymi warunkami - misiek musi być 'approved' lub należeć do panny.
Rozwiązanie proste i działa na wszystkich prawie bazach: - każdy panna ma pod siebie zdefiniowany widok w swoim schemacie bazy danych (z warunkiem OR owner_id = 13, gdzie 13 to id panny.
Rozwiązanie "eleganckie" - jeden widok dla wszystkich, baza dopasowuje uprawnienia w zależności od użytkownika:
- to są zależne od bazy rozwiązania typu "row security" https://wiki.postgresql.org/wiki/Row-security https://dev.mysql.com/doc/refman/5.0/en/stored-programs-security.html itp.
(też można i należy robić to na widokach)
Można też zdefiniować funkcję w bazie danych, która ogranicza dostęp.
Replikacji unikałbym w takiej sytuacji (o ile nie jest potrzebna do czegoś innego).
~Saper
On 2015-08-20 22:18, Marcin Cieslak wrote:
On Thu, 20 Aug 2015, spin@hackerspace.pl wrote:
Robimy bazę przejściową. Do niej baza panny B wrzuca rekordy. W bazie robimy mapowanie, normalizację, zaciągamy fotę z linka na localhost, ew. procesujemy. Taki rekord czeka na usera który mu musi zrobić translację, sprawdzić, i klepnąć mu taga 'approved'.
Każdy misiek z tagiem 'approved' jest przepychany do bazy docelowej panny A. Jeżeli jest zmiana statusu pozycji na półce tego miśka, a jego status jest approved, to baza przejściowa już z automatu wypycha to info do bazy panny A.
Coś bliżej na temat technologii, której używasz? Zakładam jakiś SQL:
- Tabela M trzyma wszystkie miśki
- Dostęp SELECT do tabeli M ma tylko naczelny niedźwiedź
- Zdefiniowany jest widok MyDearBear na tabeli M z dodatkowymi warunkami - misiek musi być 'approved' lub należeć do panny.
Rozwiązanie proste i działa na wszystkich prawie bazach:
- każdy panna ma pod siebie zdefiniowany widok w swoim schemacie bazy danych (z warunkiem OR owner_id = 13, gdzie 13 to id panny.
Rozwiązanie "eleganckie" - jeden widok dla wszystkich, baza dopasowuje uprawnienia w zależności od użytkownika:
- to są zależne od bazy rozwiązania typu "row security"
https://wiki.postgresql.org/wiki/Row-security https://dev.mysql.com/doc/refman/5.0/en/stored-programs-security.html itp.
(też można i należy robić to na widokach)
Można też zdefiniować funkcję w bazie danych, która ogranicza dostęp.
Replikacji unikałbym w takiej sytuacji (o ile nie jest potrzebna do czegoś innego).
Po stronie panny A to będzie MySQL, po stronie panny B nie wiem jeszcze, ale prawdopodobnie sql jakiś.
Problem tutaj jest taki, że panna B za nic w świecie nie zmieni swojej bazy, ani nie da dostępu write do niczego co jej. Ona jest dominująca w tym związku.
Dlatego myślę o bazie przejściowej, bo wtedy - zależnie jaką decyzję panna B podejmie odnośnie udostępniania swoich danych - będzie można do tej bazy pchać zmiany, albo kazać jej zmiany zaciągnąć, albo będzie dostawała cały dataset i robiła diffa (in b4 szatan).
Będzie się też wtedy można łatwo podpiąć pod jakąśtam pannę C jeśli będzie kiedyś taka potrzeba.
Na niej też porobi się mapowanie, deduplikację po jakimś kluczu + human approval, i zrobi się listę rekordów które będą update'owane w bazie docelowej, a które będą tylko trzymane (om nom statistics).
Będzie też można te rekordy panny B wywalić szybko gdyby coś nie teges (wywalasz tag approved i wylatują przy najbliższym update).
Tak mię się wydaje.
-
Marcin Cieslak -
spin＠hackerspace.pl