Other Software > Developer's Corner

MOANTS Database Design

<< < (3/3)

Jimdoria:
Hi Rover -

I think I'm with Mr. Franks on this one. You've defined database requirements - but we're not talking about building a database engine. We're talking about building note taking software. Program functionality comes first, starting with interaction design. Technical stuff follows on as appropriate. Why would you start working on plumbing before the blueprints are even drawn? (Note: "Because I'm a plumber!" is NOT really a good answer!  ;) )

Rover:
Database design.  I was going to put off the formal design until after we selected an engine, but it makes sense to have a high level design to help define our engine requirements.  Again this was in my head I don't know why you didn't see it there  ;D

For discussion purposes, a note is the main item in the database.  A user creates a note to record information.  The note could be a web page, image, text, or a combination of these things.  With that in mind the data we need to manage should include:

date/time stamp for each note
note identifier (internal unique)
o note title/name
o category relationship (M-M)
o text
o blob
o template
o user **

o = optional

** opens a sticky issue.  Assuming the database is avilable for anyone who can write an application to talk to it, there is no security.  Should we care that User X can in theory read data from User Y database?  This assumes that the files are on a shared PC and the database files are visible.  Need some discussion.


Normalization: How far do we want to normalize?  Should text be part of the record definition for a note or can it be in a serate linked table?  Same question for any optional field except Category, which should be in a table due to the Many to Many relationship.

Some discussion is probably needed regarding how to maintain formating linkages between images and text.  Also how do you want to store a web page?   We should probably define those standards instead of letting the application interface determine them so you don't have data that is not transportable between two interfaces.

In the end, this becomes more of a standard than an actual database definition.

Rover:
You've defined database requirements - but we're not talking about building a database engine. We're talking about building note taking software. Program functionality comes first, starting with interaction design.
-Jimdoria (May 15, 2006, 05:22 PM)
--- End quote ---
Normally I'd say your 100% right.  however in this case, we are designing an application that does not have a single user interface.  We're designing a database where you can roll your own interface to suite your need.  Now, we probably have 1 or 2 in mind to use this, but the application in this case is really data storeage.  How we input the data and how we report it is slightly irrelivant because the interface will vary according to user's individual tastes.

That being said, there are a few non-negotiables for Note-Taking software. That is what we're trying to capture here.  If you want to extend your UI to include a color preference field, then you'll need to do that in your own table.  The basics, however, should be available to any UI.

Jimdoria:
Sorry, I'd say I'm 100% right in this case, too. :D (Just kidding. Maybe only 93% right.)

You don't pour the foundation (or even set the concrete molds) before you've designed the structure. You're assuming a lot of things as given that I think are far from given.

A post in the other thread suggested using the file system as a data repository. The database needed in that scenario is worlds away from the one needed in the "store all notes in the database" scenario. I don't know that this could work, but if nothing else it shows that some of your "non-negotiables" may actually be "negotiables" at this early stage.

I still think DB req's are premature at this point, and specifying them too early runs the risk of imposing needless limits on the structure of the program. Or at least of spending time doing work that runs a high risk of being completely discarded. But it's your time, I guess. Personally, I don't think I'll be posting to this thread again - at least for a while.

Navigation

[0] Message Index

[*] Previous page