Dopisywanie dodatkowej informacji do pola w bazie danych

0

Jak w MySQL dokonać dopisania dodatkowej informacji do pola w bazie nie tracąc wcześniejszej zawartości tego pola.
Sytuacja jest taka że mam tabelę Userów opisującą ich cechy. Jedna z kolumn wymienia nazwy plików należących do Userów. Nazwy plków są w polu Text wymienione po przecinku. Teraz chcę dodać do wpisanych tam nazw dodatkową po przecinku, nie tracąc poprzednich. Mogę oczywiście próbować robić to przez jakąś dodatkową tabelę a czy jest jakiś prostszy sposób?

0
update dupa set pole = pole || 'nowa wartość'
0

Ale czemu chcesz coś takiego robić? To jest złamanie już 1 formy normalnej, a baza powinna być w 3 żeby dało się z niej po ludzku korzystać! Idę o zakład że z nazw plików korzystasz osobno, tzn gdzieś potem sobie te nazwy plików dzielisz po przecinku. Czemu więc nie zrobisz osobnej tabeli i nie użyjesz normalnego powiązania 1:n?

0

Dzięki za odpowiedzi. Shalom myślałem żeby to zrobić tak jak mówisz bo rzeczywiście później będę musiał wydobywać nazwy plików z tekstu. Ale tak po pierwszym przemyśleniu to rozwiązanie wydaje mi sie lepsze choć mogę sie mylić. Każdy User ma mieć swój wiersz w tabeli Userów z danymi podstawowymi (login, hasło itd). Myślałem o tym żeby każdemu z nich przypisać dodatkową tabelę z wymienionymi plikami jako osobne rekordy. Ale to ma być projekt forum i z czasem ilość userów może być duża (3-4 tysiące). To oznacza 3-4 tysiące tabel w bazie. Wydaje sie to dość niekorzystne wydajnościowo. Tak duża baza będzie działała pewno dużo wolniej niż baza z kilkoma tabelami i pewnymi danymi scalonymi w pojedynczych polach tekstowych (nazwy plików). Jak myślisz?

0

Ale dlaczego nie możesz zrobić tego po ludzku? Tabela Files z polami "file_id", "user_id", "file_name"?

0

Powiedz że żartujesz. Chcesz pisać własne forum a nie rozumiesz PODSTAW baz danych? o_O Masz mieć JEDNĄ tabelę dla użytkowników i JEDNĄ tabelę dla plików. Jak dla mnie to nie są tysiace tabel, tylko dwie tabele. Rozumiem że idea KLUCZY w bazie danych do ciebie nie dotarła? Otóż w tabeli Pliki wystarczy że będziesz miał nazwę pliku, jego id oraz id użytkownika (jako tzw klucz obcy)

0

Jasne że wiem co to są klucze. Zastanawiam sie tylko nad szybkością dostepu do danych. W przypadku jednej tabeli dla plików (też myślałem o tym) będę miał np 4 userów a każdy będzie miał przypisanych 20 plików (fotografii). To jest tabela z 80 tysiącami wierszy gdzie dany user (id) może się przeplatać w różnych miejscach tabeli (pliki dodawane w różnym czasie). Aby więc aby wyszukać jakie pliki posiada dany user system będzie musiał przelecieć całą tabelę do końca czyli 80 tys. rekordów. Wydaje sie to dość czasochłonne. Jak myślisz?

0
Garry napisał(a):

Jasne że wiem co to są klucze. Zastanawiam sie tylko nad szybkością dostepu do danych. W przypadku jednej tabeli dla plików (też myślałem o tym) będę miał np 4 userów a każdy będzie miał przypisanych 20 plików (fotografii). To jest tabela z 80 tysiącami wierszy gdzie dany user (id) może się przeplatać w różnych miejscach tabeli (pliki dodawane w różnym czasie). Aby więc aby wyszukać jakie pliki posiada dany user system będzie musiał przelecieć całą tabelę do końca czyli 80 tys. rekordów. Wydaje sie to dość czasochłonne. Jak myślisz?

Nie masz pojęcia, jak działają bazy i indeksy w niej.
Zamiast pisać głupoty, lepiej byś się doszkolił (doczytał)

1

@Garry na szczęście ludzie którzy piszą silniki bazodanowe i optymalizatory kosztowe są sprytniejsi od ciebie i potrafią takie cuda robić bez robienia full-table-scan. Co więcej, zapewniam cię że wybranie wszystkich plików za pomocą indeksu będzie dużo dużo szybsze niż dzielenie wielkiego stringa po przecinku...

0

Jeżeli jest to tak fajnie zoptymalizowane że przeszukiwanie wartości w tabeli po foreign key nie wymaga przeskanowania wszystkich rekordów to super. Do tej pory myślałem że tylko szukanie po indeksowanym primary key daje takie plusy w szybkości. Szukam po prostu metody do jak najmniejszej eksploatacji bazy bo forum to ciągłe używanie bazy przez wielu userów. Praktycznie każde działanie na forum to odwołanie do bazy (przeglądanie tematów, wątków postów, pisanie). Dlatego chcę jak najbardziej skrócić operacje na bazie aby się nie blokowała. Wdawało mi się że pobranie stringa z dużo mniejszej tabeli (4 tys. userów) w której szuka sie po primary key (id usera) będzie znacznie szybsze niż przeszukanie tabeli z 80 tys pozycjami gdzie id usera jest tylko foreign key'em. No i zauważyć trzeba że w samo cięcie stringa na nazwy plików dokonywane byłoby przez php a nie bazę więc zaraz po zwróceniu wyniku baza byłby zwalniana. Ale oczywiście to wszystko to tylko takie moje "założenia".

0

Brawo, przeniósłbyś operację z poziomu Bazy (która jest stworzona do szybkiego przetwarzania danych...) i wrzucił tą operację do interpretowanego języka programowania :D Na pewno przyspieszyłoby to działanie :D Zresztą co ci po tym że baza byłaby mniej obciążona (rzekomo...) skoro interpreter PHP by ci umarł?

Wyobraź sobie ze baza danych potrafi tak zrobić dla dowolnego pola na którym masz indeks...

0

No interpreter zostanie na pewno obciążony i jest to duży minus. Tylko pytanie co jest bardziej moco-żerne jeżli chodzi o zasoby procesora. Interpreter to dość prosty program, baza danych wydaje sie bardziej wymagająca - ale nie wiem. A co do indeksacji to z tego co wiem w danej tabeli mogę indeksować tylko jedną kolumnę. W Tabeli User indeksacja będzie po "user_id" ale w tabeli fotografii (80 tys rekordów) indeksacja będzie po 'foto_id" bo to jest primary key i ta indeksacj jest potrzebna dla wyszukiwania pojedynczych fotografii. Pozostałe kolumny w tej tabeli - "nazwa_pliku" i "user_id" nie byłby indeksowane. Wiec wyszukiwanie w tej tabeli fotografii należących do danego Usera po nieindeksowanym "user_id" (foreign key) musi zająć znacznie dłużej niż wyszukiwanie w tabeli Userów po indeksowanym tam "user_id" . Podobno wyszukanie konkretnej wartość w indeksowanej kolumnie wymaga tylko kilku operacji dostępu i porównania. Znalezienie tego samego po kolumnie nieindeksowanej to może być kilkadziesiąt działań. Stosunek czasów wykonania na pewno będzie przekraczał 1/20. Może w tym momencie już opłaca sie taka operacja z przerzuceniem części działań do interpretera

0

Skoro wiesz, że któregoś pola będziesz często wykorzystywał w klauzuli where, to załóż na tym polu indeks. Poza tym 80k takich rekordów w bazie to tyle co nic.

0

z tego co wiem w danej tabeli mogę indeksować tylko jedną kolumnę

piłeś? nie kodź
Na tabeli możesz mieć tylko jeden indeks primary, ale indexów secondary możesz mieć ile chcesz

1 użytkowników online, w tym zalogowanych: 0, gości: 1