Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Learning New Job Functions

0 views
Skip to first unread message

news.usenetserver.com

unread,
Jun 28, 2008, 8:51:51 PM6/28/08
to
My boss has decided that I should be moved toward more
development-oriented job functions. For about ten years I have performed
system administration work but lately I have been performing IT technician
duties. My initial migration toward development work involves creating
two applications that will have SQL databases containing data that will be
shared among seven geographically-separated sites. I have been given the
requirement that these databases be accessible through web-based submit
and receive forms.

Does anyone have some suggestions about good resources that could help
guide me in designing the structure of the databases?

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Ed Prochak

unread,
Jun 30, 2008, 8:29:52 AM6/30/08
to

You say nothing about the requirements for the applications, so we
cannot comment about the database design specifically.

I would suggest that you learn data modeling. Take a course or two at
your community college on databases. Or find a senior developer at
your company to mentor you. Also, talk to the DBA about your database
design. Try to learn both the practical aspects of the DBMS you are
using and the theory of Relational databases.

HTH,
ed

Marco Mariani

unread,
Jun 30, 2008, 9:01:47 AM6/30/08
to
news.usenetserver.com wrote:

> Does anyone have some suggestions about good resources that could help
> guide me in designing the structure of the databases?

Disclaimer: I am not a DBA. I also started as a sysadmin.

I found the following quite useful and well written:


Data Modeling Essentials - Third Edition (by G. Simsion - G. Witt)
SQL Programming Style (J.Celko)
Data and Databases; Concepts in Practice (J.Celko)

Although there is some overlap, you might benefit from several books and
grok more nuances.
Avoid traps and books with examples in mysql-ese or a deep love for
surrogate keys.

These 3 books are not about theory: if you are not bored by theory or
something doesn't click right in you head about how relations and
non-procedural stuff works, you could read "Databases in Depth:
Relational Theory for Practitioners" by C.J.Date.

If you are dealing with legacy schemas there are some recipes to keep
sanity:

Refactoring Databases: Evolutionary Database Design (S.W. Ambler -P.J.
Sadalage)

At last, when you know how to deal with correctness and clarity, you
will want to keep performance in mind from the start:

The Art of SQL (Stephane Faroult)

Philipp Post

unread,
Jun 30, 2008, 1:44:05 PM6/30/08
to
> Does anyone have some suggestions about good resources that could help guide me in designing the structure of the databases? <

Database Design For Mere-Mortals by Michael Hernandez is a good start
to get into this. It explains the important facts about the design
phase in a very clear and not too technical language.

brgds

Philipp Post

Marco Mariani

unread,
Jul 1, 2008, 5:00:39 AM7/1/08
to
Philipp Post wrote:

>> Does anyone have some suggestions about good resources that could help guide me in designing the structure of the databases? <
>
> Database Design For Mere-Mortals by Michael Hernandez is a good start
> to get into this.

Oh, I didn't read it, but I flipped through it and saw this in chapter 8:

> Note
>
> I commonly create an ID field (such as EMPLOYEE ID, VENDOR ID, DEPARTMENT ID, CATEGORY ID, and so on) and use it as an artificial candidate key. It always conforms to the Elements of a Candidate Key, makes a great primary key (eventually), and, as you'll see in Chapter 10, makes the process of establishing table relationships much easier.

If that is how he constructs his other examples, his POV greatly limits
the scope of the book. I would not recommend it.


tongue-in-cheek reference:

http://thedailywtf.com/Articles/A_Truly_ID-iotic_Design.aspx

Ed Prochak

unread,
Jul 1, 2008, 7:44:40 AM7/1/08
to
On Jul 1, 5:00 am, Marco Mariani <ma...@sferacarta.com> wrote:
[]
>
> tongue-in-cheek reference:
>
> http://thedailywtf.com/Articles/A_Truly_ID-iotic_Design.aspx

I like it. A really good example of bad design.

Philipp Post

unread,
Jul 1, 2008, 8:59:30 AM7/1/08
to
> I commonly create an ID field .... If that is how he constructs his other examples, his POV greatly limits the scope of the book. I would not recommend it. <

I agree that this is no good general advise. You could also argument
that fields should be called columns and records rows. These are some
flaws in it. However the big picture presented in the book points out
a right way in my oppinion. Further this is no advanced book, but a
first book for this and I understood that some reading from the start
was requested by the OP.

Everyone can taste it in google books and decide for his own.

Brgds

Philipp Post

Arved Sandstrom

unread,
Jul 1, 2008, 9:34:55 AM7/1/08
to
"Marco Mariani" <ma...@sferacarta.com> wrote in message
news:Xmmak.5925$f86....@tornado.fastwebnet.it...

> Philipp Post wrote:
>
>>> Does anyone have some suggestions about good resources that could help
>>> guide me in designing the structure of the databases? <
>>
>> Database Design For Mere-Mortals by Michael Hernandez is a good start
>> to get into this.
>
> Oh, I didn't read it, but I flipped through it and saw this in chapter 8:
>
>> Note
>>
>> I commonly create an ID field (such as EMPLOYEE ID, VENDOR ID, DEPARTMENT
>> ID, CATEGORY ID, and so on) and use it as an artificial candidate key. It
>> always conforms to the Elements of a Candidate Key, makes a great primary
>> key (eventually), and, as you'll see in Chapter 10, makes the process of
>> establishing table relationships much easier.
>
> If that is how he constructs his other examples, his POV greatly limits
> the scope of the book. I would not recommend it.
[ SNIP ]

Googling brings up an excerpt of that book (first page of Google results
when using "candidate" and "key" as search terms). At least based on that
excerpt it doesn't sound like he's advocating the willy-nilly creation of
surrogate keys. Possibly when he used the word "commonly" in the excerpt you
quoted, that he genuinely just meant "commonly"...as in, there was no
candidate key already, or what candidate key there was wasn't particularly
attractive.

AHS


CharlesKG

unread,
Jul 3, 2008, 1:26:55 PM7/3/08
to
My apologies. One of the applications is a casino ban form that will
be shared among seven casino sites. It has to use a browser UI and I
have MS SQL 2005 Enterprise as the backend database.

I suppose my biggest problem with that is establishing the necessary
security so that only certain users can create and update bans and
other users can only view the bans and perform searches using criteria
available on the ban form. The criteria would be items such as the
date of the ban, casino location, type of ban, etc.

The other application is a little too complex to explain in one
posting and I do not plan to start on it until I finish the ban form.

Unfortunately, there is no DBA or senior developer here. The
combination of those two positions is what I am being migrated toward.
I know that there is a lot to learn but I will gradually get to where
I can create professional databases.

0 new messages