Model dla tabeli generowanej przez użytkownika


#1

Cześć,

Potrzebuję dać możliwość użytkownikowi tworzyć własne tabele z danymi. Nie bardzo wiem jak prawidłowo zabrać się za ten problem. Poniżej schemat działania.

Użytkownik może dodać tabelę, definiując jakie kolumny będzie zawierać ( nazwa, typ danych, maksymalna wielkość pola ). Następnie użytkownik musi mieć możliwość wypełnienia takiej tabeli danymi.

Proszę o podpowiedź, z góry dziękuje.


#2

NIe wygląda mi to na dobry pomysł.

Ja bym chyba zamiast dawać użytkownikowi możliwość tworzenia tabel zbudował jakiś generyczny model, który pozwala przechowywać dość dowolne dane, ale fizycznie struktura w bazie danych będzie narzucona przeze mnie.


#3

Mówiąc dodawanie tabeli przez użytkownika nie miałem na myśli dodawanie tabeli do bazy. W bazie dane chciał bym przechowywać w jednej, może w kilku powiązanych ze sobą tabelach. Użytkownik ma mieć możliwość stworzenia własnego zestawu danych. Nie wiem czy jasno opisuje problem.


#4

mało wiemy o kontekście użycia baz tworzonych przez użytkowników

z tego co zrozumiałem do tej pory

  1. model user_db powiązanie user -> user_db

  2. model db_table powiązanie user_db -> db_table
    name -> nazwa tabeli,
    fields -> json z listą pól np. pole + typ + długość
    meta -> json z regułami walidacji
    tu pilnowanie by fields i meta miały ten sam zestaw kluczy + klucz table w meta dla walidacji “na tabelę” (wspóczuje jak w grę wchodzą jakieś wyczesane constraints)

  3. model db_data pola:
    db_table_id,
    db_row -> jeden json field z danymi (walidujesz przez db_table.meta)

opcjonalnie dla ułatwienia filtrowania dodajesz pola user_db_id user_id etc.


:biohazard: flow railsów :biohazard: trzymaj to jak najdalej od niego

:heart: sporo serwis obdżektów :heart:


Wariant z drugim connection do bazy == tyle mikro instancji bazy ile użytkowników :wink: to wydaje mi się zbyt kosztowne w deploy-u :slight_smile:


co do mojej koncepcji to zastrzegam że używałem hash fields - dynamiczne pola - w zdecydowanie mniejszym zakresie niż całe struktury tabel łączine z powiązaniami - no copy paste - to tylko koncepcja nazwy modeli/pól dość nieszczęśliwe :slight_smile:


wariant no-sql :no_entry: json fields działają całkiem nieźle (przynajmniej w postgresql) może ktoś kto użył no-sql rozwiązując podobny problem mnie skoryguje :blush:


#5

Tylko jak z dostępem i edycją konkretnej komórki, za każdym razem aktualizuje cały wiersz. Myślałem o czymś podobnym, tylko dane przechowujemy w tabeli table_cell:

table_id -> id tabeli
row -> wiersz tabeli
content -> dane komórki

W tym wypadku chyba łatwiej uzyskać dostęp do komórki i aktualizując konkretne pole nie aktualizuję całego wiersza. Tylko nie wiem jak to się ma z wydajnością…


#6

w mojej komcepcji row == content a informacje o tym jakie obiekty walidatorów użyć i co walidować przechowuje w db_table

to tylko koncept diabeł twki w szczegółach

Nic nie stoi na przeszkodzie by mieć UpdateRecordService powiązany z akcją update (klasyk) i UpdateFieldService wołany z akcji kontrolera update_field jak rozumiem edytujesz pola bezpośrednio na widoku i do kontrolera idzie info o pojedyńczej modyfikacji pola w ramach rekordu czyli 2 parametry
Trzymając się mojej koncepcji (row_id + field_name + form_value)


Napewno będziesz potrzebować maszynę stanową i dobry pomysł na DSL dla walidatorów


wydajność - jeżeli mówimy o tysiącach użytkowników -> tysiącach baz -> tysiącach rekordów w bazach to nie unikniesz kosztów - bardziej precyzyjny być nie mogę - nie znam:

  • domeny problemu
  • obecnej skali
  • nie wiem na czym to stoi

skalowania nie unikniesz - pytanie jak bardzo chcesz sobie skomplikować deploy i jak uprościsz builder tabel żeby nie zginąć w gąszczu niuansów walidacji

Prawdziwa puszka pandory to dopuszczanie zmiany reguł walidacji dla już istniejących tabel

do tego są struktury danych których SQL nie lubi przetwarzać a użytkownik skoro ma możliwość to może takich struktur użyć

Loginczym jest dla mnie że nie dopuścisz na dowolną ilość pól i dowolną głębokość powiązań między tabelami


NIe znając 3 wypunktowanych rzeczy mogę brzmieć kompletnie nieprofesjonalnie :slight_smile:

EDIT:

jeżeli “bazy użytkowników” wymagają ambitniejszych mechanik SQL niż tylko relacje 1…1 1…N to cały koncept na JSONie idzie do kosza… Jeżeli musisz zapewnić ACID to … wyjdzie drogo w deploy-u :slight_smile: