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.
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.
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.
mało wiemy o kontekście użycia baz tworzonych przez użytkowników
z tego co zrozumiałem do tej pory
model user_db powiązanie user -> user_db
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)
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.
flow railsów trzymaj to jak najdalej od niego
sporo serwis obdżektów
Wariant z drugim connection do bazy == tyle mikro instancji bazy ile użytkowników 
to wydaje mi się zbyt kosztowne w deploy-u 
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
wariant no-sql 
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 
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ą…
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:
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
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