I understand your arguments, but I'd be curious really how much performance difference there is with splitting your text field into a separate table. I've never tested nor read about how much overhead there is in permissions checking. MySQL does cache that information so it can't be much. In my case, I usually don't need to pull from a text field for a general query, only for a drill down. So I don't have to do a join for the majority of the queries, thus no performance hit. You may not have this luxury.
I think your best bet would be to setup multiple char(255) columns instead of text. There is extra coding required when adding records, but it gives you your fixed length data since the fields are padded by the database.
But here is another idea. Since your text value is not changing, what about setting it up in a separate table and loading it into a HEAP table at startup? Adding records would require updating both the HEAP table and the "real" table, but retrieval would be fast.
Just some ideas that may or may not work for you. I don't claim to know what's best for you, I'm just trying to help.
On Thursday, October 30, 2003, at 06:29 PM, Matt W wrote:
I don't think MySQL is doing what's best. *I* am the one who knows best and I don't want MySQL changing column types.
An example is a table I have where I'd like to have a TEXT column with a
value that is basically NEVER changed after being inserted. I can run
OPTIMIZE on this dynamic row length table if the value of the column is
changed to make sure the row isn't split (split rows = slower reads).
-- Brent Baisley Systems Architect Landover Associates, Inc. Search & Advisory Services for Advanced Technology Environments p: 212.759.6400/800.759.0577
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
