I must claim some ignorance, I come from the application world... but,
from a data integrity perspective, it makes a whole lot of sense to
store video, images, documents, whatever in the database rather than on
the file system external to it. Personally, I would use LOB's, but I do
not know the internals well enough to say LOBs or large columns.
Regardless, there are a lot of compelling reasons ranging from software
maintenance, disk management, data access control, single security layer
implementation, and so on which justify storing data like this in the
DB. Am I too much of an Oracle guy? I think that Postgres is more than
capable enough for this type of implementation. Is this confidence
unfounded?
Aside from disk utilization, what are the performance issues with
LOB and / or large columns? Does the data on disk get too fragmented to
allow for efficient querying? Are the performance issues significant
enough to push parts of the data integrity responsibility to the
application layer?
Thanks,
Nate
Albert Cervera Areny wrote:
> A Dimecres 01 Febrer 2006 01:32, Rodrigo Madera va escriure:
>
>> I am concerned with performance issues involving the storage of DV on
>> a database.
>>
>> I though of some options, which would be the most advised for speed?
>>
>> 1) Pack N frames inside a "container" and store the container to the db.
>> 2) Store each frame in a separate record in the table "frames".
>> 3) (type something here)
>>
>> Thanks for the help,
>>
>
>
> What if you store meta data in the database and use some PL/Python/Java/Perl
> functions to store and retrieve video files from the server. The function
> would store files to the files system, not a table. This avoids the need for
> a file server for your application while making your relational queries fast.
>
> Any experiences/thoughts on this solution?
>
>
>> Rodrigo
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 9: In versions below 8.0, the planner will ignore your desire to
>> choose an index scan if your joining column's datatypes do not
>> match
>>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>
> !DSPAM:43e70ada303236796316472!
>
>