Retrieve info from three files by search?

and not knowing where it is in 2

[kumarsena]

im writing a cms like system, where i can write and edit and delete article. its going ok, but im having a few doubts abt the edit and delete funtions. im not using databases, but flatfile, and the info is stored in following way.

one text file wiht the article itself formatted using html

one file containing the title and description of all articles in folder

one file containing the latest addition, regardless of which folder (section) they went into. also title and description. this will be included onto the front page of the site.

adding article is straight forward, btu when it comes to editing things get a bit tricky. i can retirve the info from the article file, but how do i get it fomr the two files with the article descriptions? the thing is these two files will be updated all the time and there is no way of knowing where in the file they are. so im thinking some sort of search adn delete or search and replace function...any ideas appreciated.

kumar

[kumarsena]

ive found str_replace, preg_replace and ereg replace.

any idea which one to use?

[Filipe]

My first recommendation is to switch to database storage ASAP. Indexing data for search on flatfiles is a waste of processor power, when you can set up a Postgres table with fields for the data, and a single Tsearch2 vector that will smartly index and allow you to search documents.

This means that each document, searchable information and viewable information, will be stored in a single coherent record, and can be updated simultaneously without much trouble. Plus it gives you a layer of abstraction between your HTML and your data, which is a really good practice -- especially if you ever want to format your information differently.

[kumarsena]

thanks,

sounds like a very good idea but my host does not aloow db so im left with flatfiles. any sugesstions for free hosting with databses. or cheap hosting?

[kumarsena]

and any links to postgre resources woudl also be of help...what about mySQL?

[mincklerstraat]

If you're starting fresh, I'd recommend mySQL since you'll find more tutorials, code, and resources on the web for this database. And yes, it's definitely a good idea to get yourself a db - you'll be overwhelmed at the power and possibilities, and then go into a short period of writing really awful sloppy code that is supposed to be doing everything but does nothing well at all, and then you'll get more purpose-oriented again and just write what you need, and clean.

When it comes to searching, str_replace would be a lot faster than preg_replace. It's also a whole lot easier to learn how to use. Use it when you can.

preg_replace compared to str_replace is sort of like the difference between using a database and using files. It's so much more powerful. But there's a learning curve for this one, and it also isn't quite as fast and processor-friendly as str_replace.

The ereg stuff are a bit 'old' and they're not as fast as the preg variant functions - skip ereg, learn preg instead.

[kumarsena]

yeah think i will do that, although the tough of crappy code doesnt appeal too much, but everything has a price i guess...he he

thanks

kumar

[kumarsena]

the wrong place im sure,, but still

need help with databse design for articles...any pointers...?

[mincklerstraat]

One way to start - a table with the following fields:
1) an auto-incremented ID (INT) that's indexed
2) title - varchar, 125 long
3) description - text
4) article body - text - maybe divided up into pages with a standard divider like <!--PAGEDIVIDE--> -- maybe not
5) about 4-8 fields, either INT or varchar, corresponding to your ordering principles - like topic, category, area of the website it belongs in, author who wrote it, etc. etc. If you don't use them at first, they're still there for later use.
if you make these fields INT, then a corresponding field with title, description, other info pertaining to these 'topics' or whatever you call these sorting principles
6) a field containing all of info from the above fields, except the ID, and if you use INTs for your sort principles, replace these here with the actual names of the topics or whatever - this for 'search' facility, an easy search can just be done on a single field in the table. Uses more HD space, HD space is cheap these days. This either with a regular or a fulltext index. People often don't like filling in separate fields for searching, just want one searchbox.