> Then surely "designed well" would include a normalised database?

Not necessarily. You could for example have a database that accommodates
future needs without being completely normalised.

--
Richard Heyes

+----------------------------------------+
| Access SSH with a Windows mapped drive |
| http://www.phpguru.org/sftpdrive |
+----------------------------------------+

"Richard Heyes" <richardh@phpguru.org> wrote in message
news:481F3F30.2070403@phpguru.org...
>> Then surely "designed well" would include a normalised database?
>
> Not necessarily. You could for example have a database that accommodates
> future needs without being completely normalised.

That depends on your definition of "completely normalised". Up to 3NF is
normally sufficient, whereas up to 6NF might be excessive. But any degree of
normalisation is better than not having any normalisation at all.

The point I am trying to make is that a totally unnormalised database is
something which a competent designer will tend to avoid like the plague.
Only a complete novice will throw together a database which has 0NF.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

> --
> Richard Heyes
>
> +----------------------------------------+
> | Access SSH with a Windows mapped drive |
> | http://www.phpguru.org/sftpdrive |
> +----------------------------------------+

At 1:15 AM -0600 5/5/08, Jorge wrote:
>First I would like to say that I have had PHP experience but not
>enough to say I am a PHP developer.
>
>I want to use PHP to build a site that uses MySQL, I am building it
>from scratch so I don't know where to start, should I start with PHP
>and design a database around my code, or should I designs the db and
>design the site are the db.
>
>is it just a matter of preference or is there a recommended way to do this?


Contrary to all popular belief and religion -- start with an html
page that gathers the information you need/want.

After you decide what you want to gather, then design a flat database
to store that information. A database is nothing more than a place to
store and retrieve stuff.

Don't worry about the higher orders of database design just yet, get
it to work and understand what you are doing.

If you want to better your design, then pick up a couple books on
MySQL and learn what people are arguing about. However, realize that
you can get something working quite well without being a database
expert.

It's easy to get it to work -- but, to get it to work well, takes a
bit more effort.

Cheers,

tedd

--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

On Tue, May 6, 2008 at 9:21 AM, tedd <tedd.sperling@gmail.com> wrote:
> At 1:15 AM -0600 5/5/08, Jorge wrote:
>
> > First I would like to say that I have had PHP experience but not enough to
> say I am a PHP developer.
> >
> > I want to use PHP to build a site that uses MySQL, I am building it from
> scratch so I don't know where to start, should I start with PHP and design a
> database around my code, or should I designs the db and design the site are
> the db.
> >
> > is it just a matter of preference or is there a recommended way to do
> this?
> >
>
>
> Contrary to all popular belief and religion -- start with an html page that
> gathers the information you need/want.
>
> After you decide what you want to gather, then design a flat database to
> store that information. A database is nothing more than a place to store and
> retrieve stuff.
>
> Don't worry about the higher orders of database design just yet, get it to
> work and understand what you are doing.
>
> If you want to better your design, then pick up a couple books on MySQL and
> learn what people are arguing about. However, realize that you can get
> something working quite well without being a database expert.
>
> It's easy to get it to work -- but, to get it to work well, takes a bit
> more effort.
>
> Cheers,
>
> tedd

I will respectfully (though strongly) disagree here, tedd. If you are
building a guest book and all you need is a place to "store and
retrieve stuff," store it in a file rather than a database. If you
only have one form to collect and store information, this will be more
than sufficient.

If you are doing something more complex where you need to relate
information (say, for example, forum members <-> forum topics <->
forum messages, or customers <-> orders <-> items, etc.) then you are
far better off to think about what you need to store and plan your
database first. Doing that will make your data model much better from
the start, and you can also start planning out what your HTML pages
need to be collecting as it relates to how the data is stored.

Andrew

At 10:14 AM -0400 5/6/08, Andrew Ballard wrote:
>On Tue, May 6, 2008 at 9:21 AM, tedd <tedd.sperling@gmail.com> wrote:
>I will respectfully (though strongly) disagree here, tedd. If you are
>building a guest book and all you need is a place to "store and
>retrieve stuff," store it in a file rather than a database. If you
>only have one form to collect and store information, this will be more
>than sufficient.
>
>If you are doing something more complex where you need to relate
>information (say, for example, forum members <-> forum topics <->
>forum messages, or customers <-> orders <-> items, etc.) then you are
>far better off to think about what you need to store and plan your
>database first. Doing that will make your data model much better from
>the start, and you can also start planning out what your HTML pages
>need to be collecting as it relates to how the data is stored.
>
>Andrew

Andrew:

Well, you can certainly disagree -- we all do things differently.
What works for me, doesn't work for you and vise versa -- but that's
the way of things.

I understand relational dB's and how to use them, but I don't think
the OP was talking about that, but rather getting something much more
simple up and running.

Rob, who I respect greatly, said that 90 percent of what you are
doing should be decided before you start programming. But, I never
work that way either.

I always jump right in and use the computer to design stuff. I never
resort to making a story-book layout or poster board work-up or
anything like that. I just don't work that way.

Sure, people can criticize the way I do things if they want, but I
still get things done that work and are usually under budget with
respect to money and time -- so I must be doing something right.

From my perspective, it's far better for a newbie to actually produce
something than it is to get lost in the details and never see
anything materialize. Besides, trial and error is a great way to
learn.

Oh, and I seldom use the file system for anything. MySQL works just
fine for storing things. I'm even considering Stut's recommendation
to use a dB rather than sessions -- I think there is real value there.

In any event, different strokes for different folks -- happy coding. :-)

Cheers,

tedd


--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

On Tue, 2008-05-06 at 13:42 -0400, tedd wrote:
> At 10:14 AM -0400 5/6/08, Andrew Ballard wrote:
> >On Tue, May 6, 2008 at 9:21 AM, tedd <tedd.sperling@gmail.com> wrote:
> >I will respectfully (though strongly) disagree here, tedd. If you are
> >building a guest book and all you need is a place to "store and
> >retrieve stuff," store it in a file rather than a database. If you
> >only have one form to collect and store information, this will be more
> >than sufficient.
> >
> >If you are doing something more complex where you need to relate
> >information (say, for example, forum members <-> forum topics <->
> >forum messages, or customers <-> orders <-> items, etc.) then you are
> >far better off to think about what you need to store and plan your
> >database first. Doing that will make your data model much better from
> >the start, and you can also start planning out what your HTML pages
> >need to be collecting as it relates to how the data is stored.
> >
> >Andrew
>
> Andrew:
>
> Well, you can certainly disagree -- we all do things differently.
> What works for me, doesn't work for you and vise versa -- but that's
> the way of things.
>
> I understand relational dB's and how to use them, but I don't think
> the OP was talking about that, but rather getting something much more
> simple up and running.
>
> Rob, who I respect greatly, said that 90 percent of what you are
> doing should be decided before you start programming. But, I never
> work that way either.
>
> I always jump right in and use the computer to design stuff. I never
> resort to making a story-book layout or poster board work-up or
> anything like that. I just don't work that way.

I don't do much of that either unless I want to sort some complex things
out that aren't easy to visualize in my head. When I say 90% of your DB
should be designed before you start writing code... well, I usually
thinking about the create statements (I guess some people might call
those code), not drawing charts

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

Depends on the site intent is it mainly data oriented or is the
database just a minor component of the site design?

Mine are a lot of data management so I usually do these in this order:
- define the DB elements I need first (will come back if I need to
adjust)
- work out the user pages that will be needed.
- From there I fill back with support code: form processing,
validation and DB access, reports, etc. Usually entry and validation
then once I can get data in well I then go to reports and added
features.

Sometimes when I am stuck I may start with the user screens first, as
that is what makes or breaks a lot of my programs - how it works for
the user.

Just ask yourself 'what will give me the most of what I need to get
going?' Data structures? User screens? start there. Also starting
anywhere instead of worrying about it s a lot too. :-)

Larry

At 1:49 PM -0400 5/6/08, Robert Cummings wrote:
>On Tue, 2008-05-06 at 13:42 -0400, tedd wrote:
> > Rob, who I respect greatly, said that 90 percent of what you are
>> doing should be decided before you start programming. But, I never
>> work that way either.
>>
>> I always jump right in and use the computer to design stuff. I never
>> resort to making a story-book layout or poster board work-up or
>> anything like that. I just don't work that way.
>
>I don't do much of that either unless I want to sort some complex things
>out that aren't easy to visualize in my head. When I say 90% of your DB
>should be designed before you start writing code... well, I usually
>thinking about the create statements (I guess some people might call
>those code), not drawing charts

Occasionally I scribble down ideas I want to include, but normally I
just go right to the keyboard and outline what I want to do in the
comments of the code. I fill in the code later.

In school, my teachers wanted flow-charts with symbols on them -- but
considering we only had rocks to program with (i.e., one symbol),
there was not much difference between the flow-chart and the program.
So, I bypassed the design and went straight to programming. Old
habits die hard.

Cheers,

tedd

--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

Richard Heyes wrote:
>> I do not agree that creating a database which is normalised to3NF is a
>> waste of time.
>
> It isn't always, but it is sometimes. When time is a (significant)
> factor, getting something up and running (which has acceptable
> performance) may be more impotant than creating a technically perfect
> solution. In fact creating something that is technically perfect is
> often just a pipe dream for programmers.
>
> > On the contrary, a totally un-normalised database is nothing but a
>> problem waiting to bite you in the a**e.
>
> So you can:
>
> a) Create something that gets you to market as fast as possible that is
> "good enough".
> b) Optimise/adjust the structure later.
>
> IME though, b) rarely happens.
>
> > Computer systems have a habit of
>> growing over time
>
> Really?
>
>> ...and if you don't follow the rules of normalisation your database
>> will end up as the biggest bottleneck.
>
> Granted it's more likely, but not a given. You just need developers who
> have discipline, oh and a good memory s.
>
>> Anyone who doesn't know how to reach 3NF shouldn't be designing
>> databases.
>
> Rubbish. It s, in particular for how you can optimise you structure
> without duplicating data (too much), but shouldn't be a requirement.
>

Me personally I've always found it very productive to take a few hours
before I begin coding a project, to roughly flow-chart the basics of the
application, and then layout the db on paper to get a graphical view of
the tables I'll need, how they relate or don't relate to one another.
That way when I do actually create the db I'm usually at 3NF.

--

Mark
-------------------------
the rule of law is good, however the rule of tyrants just plain sucks!
Real Tax Reform begins with getting rid of the IRS.
==============================================
Powered by CentOS5 (RHEL5)

I doubt this will have any sway on the contributors to this thread,
but I ran across a db normalization "rule of thumb" yesterday in a
tutorial for another language: "Normalize until it hurts; De-normalize
until it works."

I lean towards finding a middle ground, so this makes sense to me.

--David.