Where to start!

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 helps 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 helps.
>
>> Anyone who doesn't know how to reach 3NF shouldn't be designing
>> databases.
>
> Rubbish. It helps, 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.