At 04:05 04/04/2001 +0200, [EMAIL PROTECTED] wrote:
>To do that, I expect to build the following database :
>
>-----------------------------------------------------------------------
>Date of the document |chapter | text
>-----------------------------------------------------------------------
>1999-02-25 |editorial | blablablabla...........
> | |...............................
> | |............blbalbal
>-----------------------------------------------------------------------
>
>1999-02-25 |policy | blablablabla...........
> | |...............................
> | |............blbalbal
>------------------------------------------------------------------------
>
I don't kow if you're giving us the total definition of your db here but in
that case, there are some points that are wrong. First, You should have an
id field in this table so that each texts has its own id. And by the way, I
would do several tables, not only one. For example, one table would contain
the definition of all the documents (id, title, creation_date, author,etc),
and another one would contain the chapters which would be linked to the
documents table by the text_id field (id, text_id, chapter_type,
chapter_title, chapter_text). For the chapter_type field, there are two
schools of thought about that. Either you put directly the type
("Editorial", "policy") in the field by defining it's a char field, or you
put an id field linked to another table containing the types of chapters
(id, chapter_type_str). Some people say that is useless, although it allows
you to change the name of a chapter only by changing one field value
instead of updating as much lines in your main db as there is of that
chapter type. I'm used to do that latter way.
Anyway, to sum it up, i'd have three tables to do your thing. But Maybe
some other people can think of better architecture. I just woke up and
didn't have my shower yet. And no, I'm not a nerd because I'm already
surfing right after waking up, I just happened to come on my computer to
check an important work mail before going to shower, and that's when I saw
this mail and decided to be a good samaritan today :)
>
>
>What are my concerns :
>
>Is a database done for this kind of thing ?
Yes, most definitely. Database are the way to go for such things. The
important keyword is good indexing thou :)
>What is it better :
>- to have the text of each chapter in the database (as above)
>- to have one file for each chapter and only the adress of the file in the db
If you wanna be able to make a search in a particular type of chapters,
it'll be more efficient to split the texts in the database otherwise
you'll have to split it within your code which can be tricky and will
drastically alter the performance of your code.
>To display correctly the text, line breakdown should be kept. Is it
>possible to
>keep them in the database ?
Yes, check out the strings functions in php, they should help you do that.
(nl2br() eg). You'll just have to put some \n in the database whenever
there needs a line feed.
Later dude
--
Chand
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]