_____
From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf
Of Glenn B. Lawler
Sent: Friday, April 22, 2005 7:33 PM
To: '[email protected]'
Subject: RE: [delphi-en] Saving images - bit off topic
Sorry if I stepped on some nerves, but I had to make a point.
"Just because you have not encountered these issues yet does not mean they
do not exist."
Believe me that I did. Quite long time ago, and I don't have the code
anymore, but I have all the experience.
Now - the fact that a field cannot be part of a WHERE clause, does not mean
that it shouldn't be used. Else what's the point to have blob fields in the
database - anyway? Hum!
My point is that there are fields designated to be key, or searchable
fields, and there are fields that transport the useful load of the record,
as the address field in my light example, if you can abstract the existence
of the LIKE keyword. I could add another example with a field like
"What_client_said". Even if it is searchable with patterns is still very
difficult to imagine phrases that a client could actually say, but is easy
to search by client name and/or record date. (Please abstract again the
existence of search engines as Google.)
In my applications I had to record sometimes long texts in Memo fields. The
text was generated automatically from some travel systems (CRS.) I had to
compare them to make sure I won't duplicate the records for some expensive
processes. The solution was to add some searchable fields as the text length
and a CRC. On another project I had to store images in blob fields! The
search was done on the image name and description, or linked to other table
with an Image_ID (logos) and in no way I felt the need to search on the
content of the image - I cannot imagine somebody to have that need (unless
we talk about fingerprints or face recognition - but then we don't start
with Access in mind, but with complex systems dealing with fractal search or
neuronal nets.)
I want to stress again: near the image name and description - fields on
which you may search (and index) - you may store the file path or the blob.
If you store the path, then after finding the record you have to initiate
another search outside the database at the OS level. When you talk about
hundred or thousand of files in one or more folders - be sure that not only
the application will be slow, but also accessing the disk for whatever else
purpose!
Having the data stored in a blob field has also another advantage: the data
may reside on a separate (and fast) server, and you may move it easily when
you scale the application, or change the db system. Incremental backup, etc.
On the other hand - can you see aside your affirmation the stupidity of all
those software engineers and analysts out there that have put Blob fields in
databases?!?
Thank you for your time and consideration,
Horia
> "If you can't search using the data, it doesn't belong in a database." -
> This is a stupid statement: there are fields in a database used for search
> and fields to hold data. Let's consider for example a phone book in the
way
> it was designed as a book: you may search using the name and find the
> address and phone number. While a database implementation can search also
> using the phone number, the address may create problems: punctuation,
extra
> blanks etc. This does not mean that the address place is not in the
> database!
You are missing the point. You cannot use any kind of blob data in a query
clause, period. In your address example, you can still use LIKE to search
within the address, and the address itself is text, so you could, for
example,
sort by the address.
Putting the data in the database cannot add any functionality and could very
well cause a number of other problems with hitting the maximum size limit
of the database or backing up the database, etc. If YOU want to put blob
data in your database, go ahead, but think before call someones analysis
a stupid statement. Just because you have not encountered these issues
yet does not mean they do not exist.
Glenn Lawler
-----------------------------------------------------
Home page: http://groups.yahoo.com/group/delphi-en/
To unsubscribe: [EMAIL PROTECTED]
_____
Yahoo! Groups Links
* To visit your group on the web, go to:
http://groups.yahoo.com/group/delphi-en/
* To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
* Your use of Yahoo! Groups is subject to the Yahoo!
<http://docs.yahoo.com/info/terms/> Terms of Service.
[Non-text portions of this message have been removed]
-----------------------------------------------------
Home page: http://groups.yahoo.com/group/delphi-en/
To unsubscribe: [EMAIL PROTECTED]
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/delphi-en/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
