Re: Storing Video's or vedio file in DB.

On Wed, Dec 17, 2014 at 3:39 AM, VENKTESH GUTTEDAR
<venkteshguttedar(at)gmail(dot)com> wrote:
> Hello,
>
> I am using PostGreSQL 9.3.5 and DJango1.7.5 and python 3.3.
>
> I am working on a application where i will get video files from mobile
> app, and i have to store in the server,
> so my question is how do i store video's or video files in DB, or do i
> need to store only the link of that video file, if yes then where i have to
> store the file and how to access that file to display in an html page.
>
> if anyone is helping me out then give me all details related to storing
> videos in db, not just hints. like (what datatype i have to use.? how to
> encode and decode.? how to accept files through http post)

Storing files in the db:
*) 1 gb limit (2 gb for large objects)
*) how you read and write the data really matters. to do this
seriously, writing the client in C and using binary wire format is
suggested
*) you can manage binary transfers in context of transaction, which is
nice (no db/fs sync issues)
*) backups will become a real headache using standard pg_dump methods
*) database will do some compression for you. however be advised pg
compression is a cpu cruncher
*) memory consumption can be multiples of largest file size

Storing files in the fs
*) have to manage database records as pointers. synchronization issue suck
*) backups will still suck
*) performance will be somewhat faster depending on how exactly the data is read
*) memory consumption is minimal

Personally having done it both ways I personally don't recommend
storing files in the database if they are going to be very large which
I would estimate to around 10mb or so assuming you have lots of data
to store. There are just too many cases where pg will open up the
whole file in memory where a well written streaming interface against
the o/s will send it right off the disk. Also in my opinion to have
anything approximating good performance in pg with binary transfers we
are definitely talking a C client.

File systems have been aggressively enhanced over the years to try and
keep fragmentation low in the face of high write activity. The
database doesn't do this and if you are dealing with a large amount of
files in the face of concurrent updating and deleting I expect you
could start running into severe fragmentation issues over time.

merlin