Data Type Handling Structure

There needs to be a better way to handle and index content. This is my idea:
– Base “content” table
— Title
— Date
— Author
— Tags
— Content
— type
— typeid (threadid, articleid, etc.)

– Thread
— All Thread options

– Article
— Article fields

( – = mysql table)
There would be a base content table with the fields above. This is the table that our search engine processes. Then every type of content “extends” this table. This way content can easily be changed (deleted from old table added to one and the id changes on the base table). This system would mean the contents actual id (the ‘content’ table’s id) would stay the same and therefor still accessible through its old URL. This also allows different types of data types to keep there special fields separate and not have a massive table with loads of data, that may only use a ⅓ of the fields.

Views: 13

4 thoughts on “Data Type Handling Structure”

  1. nexia dit :

    that’s a detail i had in mind but had no real solution about… you bring the best version so far…. yeap.

    i will try to write a bit about this, the way i see it, in the week-end… i’m finishing a website and then take a week to relax before starting the project…

  2. Drew dit :

    Ok I’ve started making a core that could be used for anything and that I want to be the base for this project

  3. Drew dit :

    Oh and on the base table we need a URL field for SEO friendly URLS

  4. nexia dit :

    hum, ok?! and….

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

En savoir plus sur Un Papa Pro

Abonnez-vous pour poursuivre la lecture et avoir accès à l’ensemble des archives.

Continue reading