The "Freeola Customer Forum" forum, which includes Retro Game Reviews, has been archived and is now read-only. You cannot post here or create a new thread or review on this forum.
I think I've come up with quite a good way of storing data and using keywords to represent what it is, so I'm making pocketmonkey into a big database that anyone can add to. It's mainly an experiment, and because it's easy to put together quickly and is automated, so I won't need to touch it. That's working PHP there, with a maximum results returned, and a limit for each page, which it's working from.
Any opinions/suggestions would be welcome.
EDIT: Some of the text in the images looks a bit ropey, but that's because I changed the colours after it had been made into the gif. I'm re-doing them with the outer glow like the image in the corner - although that's not important.
Setup a database with the correct indexes and compare the execution time to the directory/filesystem method to see for yourself.
> It'll use basic PHP string functions, and the mkdir function, and
> (hopefully) will be quite quick because it's searching for
> directories, not having to go through a whole load of data to return
> matches (although essentially it is, I mean it's just narrowing how
> much data has to be trekked through).
It'll work of course. However, modelling things like this is exactly what relational databases are for. You -might- get better performance out of directories/files with a small dataset but as it gets larger you'll find something optimized for the task (ie a relational database) is better.
The other point is that already you've reached the limit of files/directories, if you want to add more information (like related keywords for instance) things get very messy + slow.
Kinda off topic, I know... But nevermind :D.
> Well, why not tell us what the idea is? You've asked for
> comments/suggestions without really giving us much to comment on. :)
Ok, well basically (and remember, it's just an experiment, has probably been done before, and probably won't work) you'll get three fields: "Description", "Keywords", "Supporting URL".
The keywords are broken down into single terms, which then become the categories for search. A directory is made of each keyword if it doesn't already exist, and into each directory goes a reference of the unique numerical ID for the Description. That way you can cross-reference multiple keywords, which have automatically been categorised. Then you'll be able to sort the results by how often they've been viewed, when they were entered, and most importantly - how many of the terms match up to your original search string.
It'll use basic PHP string functions, and the mkdir function, and (hopefully) will be quite quick because it's searching for directories, not having to go through a whole load of data to return matches (although essentially it is, I mean it's just narrowing how much data has to be trekked through).
> Kinda, but it's more a big experiment to see if this idea for storing
> stuff works. Hopefully it will, I've thought it out well. Probably
> been done before, but it keeps the brain ticking over.
>
Well, why not tell us what the idea is? You've asked for comments/suggestions without really giving us much to comment on. :)
Also, thinking of making it so that you need a username and password to contribute - that way you can avoid any retarded entries (which I'm sure it'll get used for), or the user can be banned completely. Would aid in seeing how reliable a piece of information is too, if the user has entered lots of similar entries.
> I can see what you are aiming for and that is seriously forking cool.
You can see more than me. What is it exactly? Looks like a search facility?
> Does nothing work yet? :c(
Nah, that's just testing the page skipping. Won't take long to make, don't know why I haven't already. Oh that's right, I'm lazy...
Honestly.
I'd love to see it in proper action though, you know, searching for stuff.