[thelist] addressbook table design [sql]

[Jay Dorsey]

Actually, if your database gets very large you should experience better
performance if you write your joins and SQL statements properly
(selecting the columns you need vs. using SELECT *, adding the proper
criteria on the joins so you don't get the cartesian product).  In most
cases a normalized database will outperform one that is not.  If you
haven't worked with joins before they're really quite simple (and
clever).  Using Access you can even create the joins visually, then view
the SQL statement you would need to pass via whichever language you're
using in order to get the same statements back.

I've found that when we're developing new products here at work, we're
most always sketching out the what the database will look like -- it
helps to connect all the relationships among the data and see the big
picture a little more clearly.

If the project is small, and you know it will stay small, using the
database you had mapped out in your first e-mail will work just fine.
It will most definitely be easier to code for than the one I suggested
(you don't need to build tools to create and edit TYPE's, etc; you'll be
able to add items to the database without transactions, etc.)

Good luck!

jay



Aleem Bawany wrote:

> That's a good idea although it will add overhead because
> I will usually want to display all the user information
> and this will meaning running the query on two tables.
> It's sounds like a space vs. performance thing, but
> correct me if I'm wrong (frankly this database will be
> quite small but it's still an exercise).
>


--
Jay Dorsey
evolt at jay dorsey dot com