Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re: Question about properly laying out a database

by chip (Curate)
on Dec 12, 2001 at 02:42 UTC ( [id://131089]=note: print w/replies, xml ) Need Help??


in reply to Question about properly laying out a database

I suggest you use a real database like PostgresQL or at least MySQL. They're not that hard to set up, DBI is wonderful, and you can query on any field with great simplicity.

Failing that, you can keep your database in a flat file and use DB_File to create multiple indices into that flat file.

    -- Chip Salzenberg, Free-Floating Agent of Chaos

  • Comment on Re: Question about properly laying out a database

Replies are listed 'Best First'.
Re: Re: Question about properly laying out a database
by sligi (Sexton) on Dec 12, 2001 at 04:09 UTC
    I suggest you use a real database like PostgresQL or at least MySQL. They're not that hard to set up, DBI is wonderful, and you can query on any field with great simplicity.

    This would be my suggestion, too. It also gives you the benefit of scalability - if your database is so designed.

    To help you on your way, jeffa has written an article (Migrating a 1NF table to multiple 2NF tables) that gives very good pointers on db design. There are also good links at the end of that article and it's replies so you might want to check them out.

    --
    sligi

      My initial reaction as well was to suggest a DB like MySQL, but on further consideration... I've worked on a website with over 8000 entries where each entry had about 15 pieces of metadata, all of which was stored in DBMs. It's worked reliably for over five years.

      Question to the questioner: is this the first brush at this sort of system that your employer has attempted? If so, don't try to get it perfect, just get something out there that works, even if you end up rewriting the whole thing again in 6 months. It's unavoidable that the requirements will change, and it's futile to spend time now implementing a heavyweight architecture where the problem domain isn't clear.

        OOooo... *very* nice phraseology in your use of "problem domain."

        That's going in my non-technie I-need-to-speak-with-managers folder. :)

        very nice.

        fongsaiyuk

        My employer is the type that says, "Show me a working prototype and then we'll refine it." It's quite aggravating when the functionality isn't fully nailed down, so I am definately going to stick with DB_File.

        The suggestion for normalizing the database was EXACTLY what I needed. (thanks joealba!). I've done that and it has drastically improved the database. I have some books on MySQL coming soon, and I intend to tackle learning it quite soon. Who knows... perhaps I'll be rewriting the script 6 months later. Question though: how stable is MySQL in comparison to say, a DBM or a flat file for small (under 5000 entries) databases? Is it realistic to think that I could set up a system that allows them to add, edit, and remove records with a web interface and not have to be there to maintain it? I have yet to work with it very much, so it will be a challenge :-)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://131089]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (2)
As of 2024-04-24 23:00 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found