Posts Tagged ‘design’

Full-database draft #4

Wednesday, January 30th, 2008

After having had the hard start-ups after the holidays, we gathered our strength, and got back working on this project. For those of you who are looking for a download that provides a fully functional wiki, blog & forum, we’ll have to disappoint you: There is none ATM. All we’ve done so far is thinking of some database-design.

Of course we’d like to elaborate the current draft, but most of it speaks for itself (at least we think it does). If you have any questions, feel free to ask (leave a comment, that is).  There’re two files attached, one is a PostScript containing a visual representation of the proposed database, the other file is a plain/text file, containing the sql-statements of the design.

For those who were involved in #3, but were not involved in draft #4,  that may be right. I just noticed a couple minor mistakes in #3, and decided to fix those myself (1:15 am, pretty quiet on IRC).

Full-database draft #4 (PostScript)
- Full-database draft #4 (SQL)

Entries database design

Wednesday, December 26th, 2007

For now the biggest point of disscussion is the database design. Because the entire application is based on a database, it would be a huge mistake to scamp this design. The idea is simple, every piece of text is essentially the same, this is why we (plan to) have a table with two rows only, an identification-row, and a row with the text. Depending on the kind of entry (blogpost, wiki-page, etc) other data needs to be saved that’s what we use the table metadata for. For this, you could think about title, order (forumcategories e.g.) and the type
of contents (forumthread, forumcategory, blogpost, etc). We’ll also support tagging, because
it will happen most often that tags are used more than once,
we’ve chosen to use a many to many relationship for these with the entries. Then there’s the table what it’s all about, the table that defines the relationship
between 2 or more entries here

Someone also wondered why have fixed ‘types’ for each entry. We basically don’t because you can add just as many type-metadata’s per entry as one wants.

The proposal