Re: speed
From: windandwaves (winandwaves_at_coldmail.com)
Date: 02/21/05
- Next message: steve: "Re: Re: slash dot like script?"
- Previous message: Henk Verhoeven: "Re: speed"
- In reply to: Henk Verhoeven: "Re: speed"
- Next in thread: Geoff Berrow: "Re: speed"
- Reply: Geoff Berrow: "Re: speed"
- Reply: Henk Verhoeven: "Re: speed"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 21 Feb 2005 12:36:10 +1300
"Henk Verhoeven" <news1@phppeanutsREMOVE-THIS.org> wrote in message news:cvb64q$12e$1@news3.zwoll1.ov.home.nl...
> Hi Nicolaas
>
> It is easy to put all data in one table, but it is even easier to put a lot of errorneous data in one table. Soon you (or your end
> users) will experience 'database pollution'. When the table holds repeated data (if you do no databas desing it usually does) the
> pollution gets really irritating as things that somehow belong together can in practice often not be found 'together' in the
> database.
>
> To make a long story short, a well designed database is a good foundation for proper application that helps the users to maintain
> the data and prevent database pollution. So i suggest speed should not be your only design criterium. But IF your only concern is
> speed: why don't you just try it out?
>
> Greetings,
>
> Henk Verhoeven,
> www.phpPeanuts.org
>
> P.S. The aim of well designed code is very similar to a well designed database: make maintenance easier (i mean maintenance of the
> code). So are the means: avoid repetition. So learning about database design may in time bring you more then 'just' statisfied end
> users ;-)
>
> windandwaves wrote:
>
>> Hi Folks
>>
>> I am putting together a couple of tables in PHP/MySql that are rather large:
>>
>> 137 fields with at least about seventy medium text field.
>>
>> The table only contains about 500 rows and will never grow substantially (well, it would be nice (they are members).
>>
>> I could have created a dozen or so tables, which would have been a lot sexier from a database design perspective, but as I am a
>> PHP newby, I did not like that idea.
>>
>> Should I be worried about speed? and if so, how I can I measure speed.
>>
>> I know it all depends.
>>
>> I use a standard ISP package (not a dedicated server). I expect only a handful users of the website at the same time. These
>> large tables are read by a page that displays all the information (address, characteristics, prices, etc...) from all 136 fields.
>> No difficult queries are used at all.
>>
>> I would love to hear any experiences that you may have had that can help me.
>>
>> - Nicolaas
Maintainabilility is my main concern. In that way I designed the database. However, I was worried that I may perhaps give away
too much speed.
I totally understand your point above. I usually make supersleek databases with not a dot of repeated info. However, you can go too
far in normalisation.
In this particular instance. We are talking about 500 B&Bs, each with their own pieces of information. For example, each B&B has a
list of about 15 facilities. About 10-20% of them are repeated, so I could put it in a table like this:
Main table
unique facilities list
table with link between main table and facilities
That would be the proper way to do it. But all the extra SQL, in my opinion, in this instant, with only 10-20% repeat, does not
weigh up against the joy of having the fields F1 to F25 in the main table.
Search wise it is obviously a little harder to search 25 fields, but I simply make one field with all the words in it everytime the
user updates their data (this fields is called Keywords) and then search that. I know it is really ugly database design, but it
allows me to achieve my goal (finish the website!).
Cheers
- Nicolaas
- Next message: steve: "Re: Re: slash dot like script?"
- Previous message: Henk Verhoeven: "Re: speed"
- In reply to: Henk Verhoeven: "Re: speed"
- Next in thread: Geoff Berrow: "Re: speed"
- Reply: Geoff Berrow: "Re: speed"
- Reply: Henk Verhoeven: "Re: speed"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|