Hello there,

in former times (i. e. Borland Paradox) there was a data type named "Blob"
(= Binary Large OBject) which was used to store pictures and/or documents.

Does Postgres has a similar datatype? What is about varbin?

Thanx

Frank

On 18.10.2006 10:46, Frank Werner wrote:
Reading the documentation often helps...

http://www.postgresql.org/docs/8.1/static/datatype.html
http://www.postgresql.org/docs/8.1/s...pe-binary.html

robert

"Robert Klemme" <shortcutter (AT) googlemail (DOT) com> schrieb im Newsbeitrag
news:4pm85jFjnfqaU1 (AT) individual (DOT) net...
I read the documentaton already. Unfortunately my question was not clearly
answered.

Frank Werner

Begin <eh4qjb$lpj$03$1 (AT) news (DOT) t-online.com>
On 2006-10-18, Frank Werner <fhwerner (AT) lycos (DOT) de> wrote:
You didn't mention that.


Interpreting your question as ``does PostgreSQL allow for unspecified
binary data to be stored?'', then ``The bytea data type allows storage
of binary strings'', at the given URLs, would count as a clear answer.

If you ment something else, you could rephrase your question, perhaps?


--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.

"jpd" <read_the_sig (AT) do (DOT) not.spam.it.invalid> schrieb im Newsbeitrag
news:4pmb7qFjln9gU1 (AT) individual (DOT) net...

You are absolutely right! Sorry! The more precise form of my question is

"What datatype would experienced programmers use to store f. e. a
Word-Document or a photo?"

Thanx for all answers (I program with Coldfusion)

Frank Werner

Frank Werner <fhwerner (AT) lycos (DOT) de> wrote:
Probably bytea.

There are also Large Objects
(see http://www.postgresql.org/docs/8.1/s...geobjects.html)
but they offer few advantages (2 GB instead of 1 GB maximum, more
sophisticated manipulation functions) and some drawbacks (no permissions,
possible data inconsistencies).

I'd say: use bytea unless you have good reasons to do otherwise.

Yours,
Laurenz Albe

Begin <eh4u0u$5rc$01$1 (AT) news (DOT) t-online.com>
On 2006-10-18, Frank Werner <fhwerner (AT) lycos (DOT) de> wrote:
Personally, I'd likely prefer to store them on a filesystem and
pass an URL instead of streaming the data in SQL. But then I also
like using static pages, using run-for-every-update instead of
run-for-every-retrieval scripts, and generally simplifying wherever
possible. I'd also use pdf or something equally open and well
documented. :-)

If it has to be in the database, bytea would be a good bet.


--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.

On 18.10.2006 14:06, jpd wrote:
But you are aware of the drawbacks of this approach? Possible
inconsistency, missing TX support etc. come to mind. Also, I regard an
application simpler that has to pull things from the DB only vs. an
application that goes to a DB *and* the file system. You just need one
backup concept etc.

Kind regards

robert

Begin <4pml75Fja5pnU1 (AT) individual (DOT) net>
On 2006-10-18, Robert Klemme <shortcutter (AT) googlemail (DOT) com> wrote:
I am. I probably should have mentioned that, but anyway.


If you only look at one application, yes. If you look at ``making a
website'' (the OP mentioned coldfusion), you pull in, well, after
the OS, a webserver, coldfusion, configuration for all that, the
coldfusion-enabled html files, and so on and so forth. Nevermind the
database, its configuration, the schemas, and the data.

If you want to keep that in sync, you're likely looking at some content
management system, and for consistency you'd probably have to make that
self-referential as well. So adding a couple of checks for url columns
referencing datafiles somewhere in the system then isn't that much of a
problem. I'll admit that putting literally everything in a database has
its elegance, but the model itself only holds up to a certain point and
might not be all that practical beyond that. You did mention backups,
and a backup solution also needs to back it all up together.

Filesystems and http are optimized to hold and transfer files, and
SQL is not. You also don't gain very much of the benefits of SQL
functionality because blobs tend to be opaque. So while they are useful
whenever they're necessairy, making them not necessairy and doing
without does have its own upsides as well.


--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.

On 18.10.2006 14:59, jpd wrote:
But you save yourself the hassle of dealing with one additional
component, namely the file system. If you have product data then it's
more consistent to store product images in the DB as well. If you are
just talking about a fixed set of files (like a general EULA etc. that
would rather be considered part of the application, then that is better
dealt with in the file system or whatever the content management system
provides. I probably should have made that distinction from the start.

What point exactly do you mean?

From my experience file systems don't do very well with large amounts
of files in a single directory. If you start distributing files across
several directories you'll be better off by just using a database's
built in indexing which is exactly built for that.

Kind regards

robert