[ORACLE] Dodanie kolumny typu BLOB - =?ISO-8859-2?Q?wp=B3yw_na?==?ISO-8859-2?Q?_wydajno=B6c?=
jerry - 04-01-2007 14:09
[ORACLE] Dodanie kolumny typu BLOB - =?ISO-8859-2?Q?wp=B3yw_na?==?ISO-8859-2?Q?_wydajno=B6c?=
Witam,
W schemacie jest tabela bardzo często odpytywana przez aplikacje.
Pojawiło się wymaganie dodania kolumny typu BLOB w celu trzymania w
bazie obrazka (ok 80 - 100 KB). Obrazki muszą być w bazie - to odpowiedź
na ew. sugestie by trzymać poza oracle.
Mam wątpliwosc co będzie bardziej optymalne czy dodać tę kolumnę BLOB do
istniejącej tabeli czy dodać osobną tabelę na BLOBy i FK do niej?
Dodam, że docelowo każdy wiersz tej tabeli będzie musiał mieć ten tą
kolumne BLOB uzupełnioną (not null). Zapytania do tej tabeli są
najczęstszymi zapytaniami w systemie i zawsze mają sprecyzowane które
kolumny są wyciągane.
Uważam, że rozwiązaniem korzystniejszym jest osobna tabela w osobnej
przestrzeni by nie zwiększać tak drastycznie rozmiaru dotychczasowej
tabeli. Czy idę właściwym tropem?
Z góry dziękuję za sugestie i rzeczowe argumenty które pozwolą mi
podjąć decyzje.
=?ISO-8859-2?Q?Micha=B3?= Kuratczyk - 04-01-2007 14:09
jerry wrote:
> W schemacie jest tabela bardzo często odpytywana przez aplikacje.
> Pojawiło się wymaganie dodania kolumny typu BLOB w celu trzymania w
> bazie obrazka (ok 80 - 100 KB). Obrazki muszą być w bazie - to odpowiedź
> na ew. sugestie by trzymać poza oracle.
> Mam wątpliwosc co będzie bardziej optymalne czy dodać tę kolumnę BLOB do
> istniejącej tabeli czy dodać osobną tabelę na BLOBy i FK do niej?
http://download-uk.oracle.com/docs/c...b14249/toc.htm
Przeczytanie nawet samego pierwszego rozdziału Introduction to Large Objects
powinno dać Ci odpowiedź (ale reszta też nie zawadzi).
--
Michał Kuratczyk
dap - 04-01-2007 14:10
> Uważam, że rozwiązaniem korzystniejszym jest osobna tabela w osobnej
> przestrzeni by nie zwiększać tak drastycznie rozmiaru dotychczasowej
> tabeli. Czy idę właściwym tropem?
Ja bym tak zrobił. O ile możesz zrób nawet osobne Tablespace dla tej
tabeli, w razie czego łatwiej o backup i recovery.
dap
=?ISO-8859-2?Q?Micha=B3?= Kuratczyk - 04-01-2007 14:10
dap wrote:
>> Uważam, że rozwiązaniem korzystniejszym jest osobna tabela w osobnej
>> przestrzeni by nie zwiększać tak drastycznie rozmiaru dotychczasowej
>> tabeli. Czy idę właściwym tropem?
> Ja bym tak zrobił. O ile możesz zrób nawet osobne Tablespace dla tej
> tabeli, w razie czego łatwiej o backup i recovery.
Ale przecież można umieścić logicznie LOBa w głównej tabeli, a trzymać go
osobno, choćby w innym tablespace, czy wręcz poza jakimkolwiek tablespace.
http://download-uk.oracle.com/docs/c...g.htm#i1006574
--
Michał Kuratczyk
Lucyna Witkowska - 04-01-2007 14:10
jerry <j@op.pl> napisał:
> Uważam, że rozwiązaniem korzystniejszym jest osobna tabela w osobnej
> przestrzeni by nie zwiększać tak drastycznie rozmiaru dotychczasowej
> tabeli. Czy idę właściwym tropem?
Nie. Tak robilo sie dla typow LONG i LONG RAW, dla typow LOB tego nie
potrzeba robic.
Jesli w tabeli jest kolumna LOB, to powstaja osobne segmenty
trzymajace indeks i zawartosc tej kolumny. Oracle to robi "w tle".
W segmencie wlasciwej tabeli trzymane sa tylko odnosniki do tych
segmentow. To co chcesz zrobic to IMO niepotrzebne dublowanie struktury.
Przy tworzeniu tabeli mozna tez podac w jakiej przestrzeni maja byc
tworzone segmenty zawartosci i indeksu dla LOBow.
Pozdrowienia,
--
Lucyna Witkowska
dap - 05-01-2007 00:04
> Ale przecież można umieścić logicznie LOBa w głównej tabeli, a trzymać go
> osobno, choćby w innym tablespace, czy wręcz poza jakimkolwiek tablespace.
Mozna, ale wiesz jak z reki sprawdzić parametry STORAGE dla LOBa, ja nie
:D? Wydaje mi się, że osobna tabela jest bardziej przejrzystym
rozwiązaniem. Dodatkowo jakoś nie lubię zmieniać definicji tabel online.
Zresztą w razie wersjonowania czy np. potrzeby zrobienia miniaturek
będzie to bardziej elastyczne, niż dodawanie kolejnej kolumny...
dap
=?ISO-8859-2?Q?Micha=B3?= Kuratczyk - 06-01-2007 00:02
dap wrote:
>> Ale przecież można umieścić logicznie LOBa w głównej tabeli, a trzymać go
>> osobno, choćby w innym tablespace, czy wręcz poza jakimkolwiek
>> tablespace.
> Mozna, ale wiesz jak z reki sprawdzić parametry STORAGE dla LOBa, ja nie
> :D?
Tak jak zawsze przez DBMS_METADATA.GET_DDL? Chyba, że nie rozumiem pytania.
> Wydaje mi się, że osobna tabela jest bardziej przejrzystym
> rozwiązaniem.
Tyle tylko, że Oracle de facto to właśnie robi w tle. A skoro on to już
robi, to po co robić to samemu? Tym bardziej, że te automatyczne mechanizmy
zadziałają także dla tej Twojej dodatkowej tabeli, więc będziesz miał
tabele główną połączoną z tabelą na LOBy, a Oracle i tak te LOBy będzie
trzymał osobno.
> Dodatkowo jakoś nie lubię zmieniać definicji tabel online.
Przykład był akurat jak to zrobić po utworzeniu tabeli, ale można oczywiście
podać to już przy CREATE TABLE. Chyba, że znowu czegoś nie rozumiem. Może
jest za wcześnie? ;-)
--
Michał Kuratczyk
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
Oracle 19g +Insert +Insert +Insert...
MSSQL Express czy Oracle Express
[Oracle, Toad] Zaladowanie obiektu w TOAD
[Oracle][Reports30] 10G nie dziala razem z Reports3.0
[Oracle] catalog.sql i catproc.sql - bledy
klient oracle (zmiana domyslna klienta oracla)
[oracle] [xml] XML na bazie istniejacej struktury ?
[Oracle] W jaki sposób skopiować całą zawartość schemy jednego użytkownika do nowo utworzonego użytkownika?
klient Oracle 10g SE a Windows 98 SE
Oracle Standard Edition One - czym sie rozni od wersji standard iexpress?
zanotowane.pldoc.pisz.plpdf.pisz.plptsite.xlx.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
