Czy tworzenie tabeli w środowisku wykonawczym w sposób dynamiczny na podstawie interakcji użytkownika jest dobrą lub złą rzeczą dla aplikacji internetowej? (Mówię java, ale pytanie prawdopodobnie dotyczy więcej).Tworzenie tabel dynamicznie w środowisku wykonawczym
Tabele są na ogół kluczowe dla interakcji użytkownika z bazą danych. W związku z tym brak tabel jest śmiertelny.
Z tego wynika, że tworzenie tabel w locie, w czasie wykonywania, jest złą praktyką, ponieważ oznacza to, że nie ma gwarancji użytkownika. Jeśli instrukcja CREATE TABLE nie powiedzie się, z dowolnego powodu, użytkownik jest wypchany.
Tak więc dobrym pomysłem jest unikanie procesów biznesowych opartych na tworzeniu tabeli w czasie wykonywania. Zwykle są to obejścia, z wyjątkiem bardzo szczególnych okoliczności.
W pewnym stopniu zależy to od smaku RDBMS stanowiącego podstawę wniosku. Na przykład Oracle ma koncepcję globalnych tymczasowych tabel, która usuwa wezwanie do dynamicznego tworzenia tabel niemal we wszystkich okolicznościach. Ale nawet bez takich wymyślnych funkcji, zwykle istnieją sposoby obejścia tego problemu: na przykład dodanie kolumny USERNAME do tabeli i utworzenie na niej widoku zawierającego filtr WHERE na USERNAME=USER.
Zasadniczo DDL jest drogi do wykonania, jeśli chodzi o czas i zasoby systemowe. Tworzy złożoność transakcyjną. Jest to ryzykowne: jeśli się nie powiedzie, użytkownik nie może kontynuować. Z tych wszystkich powodów należy tego unikać.
Generalnie nie, to nie jest dobry pomysł. Zwykle cokolwiek by tworzyli, byłyby zapisy w tabeli.
Są jednak wyjątki, na przykład w przypadku tworzenia konta hostingowego dla nich, z tabelami, które następnie będą używać osobiście.
Nie podając więcej szczegółów na temat sytuacji, nie mogę podać lepszej odpowiedzi.
Tak jak w przypadku SQL-Server, bardzo powszechną praktyką jest tworzenie tabel tymczasowych, zmiennych tabelarycznych, używanie funkcji o wartościach tabelarycznych itp. Na przykład, byłoby to wykonywane w przechowywanej w bazie danych procedurze wywoływanej przez twoją sieć Web. podanie.
Nie ma twardych i szybkich zasad, które wiem, czy to jest dobre, czy złe - w zależności od sytuacji.
Domyślam robisz coś takiego:
table_username(
id,
userfield1,
userfield2,
ect...
)
Alternatywą byłoby utworzyć tabelę statyczną tak:
table_userfields(
id
userid
fieldname
fieldvalue
)
Jedynym problemem jest to, że wartość pola będzie prawdopodobnie musiał być wielkim varcharem.
Ale twoje podejście nie jest złe, zależy od twoich szczególnych potrzeb.
który nie wydaje się bardzo wydajny. –
@ mark-w Nie dla twojego scenerio w ankietera ... Chciałem tylko zapisać pewne ustawienia użytkownika. – AJC
Generalnie nie jest to dobry pomysł, chyba że wszyscy użytkownicy są dobrymi modelarzami danych. Większość użytkowników nie tworzy dobrych projektantów baz danych. Przeciętny użytkownik nie myśli o takich rzeczach jak wybór właściwego typu danych i kluczy, projektowanie schematów kodowania, analiza zależności czy stosowanie zasad normalizacji. Tworzenie dobrych modeli danych jest trudne, dlatego zwykle pozostawia się je specjalistom.
użytkownik nie tworzyłby tabeli. Byłoby to zrobione w tle przy ścisłej kontroli i na pewnym poziomie enkapsulacji. –
na przykład aplikacja do wymyślania stylu CMS.Jeśli użytkownik tworzy kwestionariusz, zastanawiam się, czy warto jego dynamicznie utworzyć tabelę, która zawiera specyficzne "typy" ich pytań (boolean, string int), a nie generyczne dla wszystkich różnych kwestionariuszy. –
W tym celu nie twórz tabel, skończysz z dużo zbyt wieloma tabelami. Istnieją sposoby na strukturę bazy danych do obsługi typów dynamicznych. Najłatwiej jest mieć wiele tabel - po jednym dla każdego typu, następnie w tabeli głównej należy uwzględnić klucz obcy plus nazwę tabeli zdalnej, do której ma prowadzić link. Nie można ustawić formalnej relacji w strukturze bazy danych między nimi, ale można to zrobić za pomocą serii zapytań UNION z łączeniami dla każdego typu. – Ariel