Page 3 of 3

Posted: Thu Aug 03, 2006 10:22 am
by Benjamin
md5 the link and store it in a database.

Posted: Thu Aug 03, 2006 10:31 am
by Jenk
Do you mean base64 it? MD5'ing it won't achieve much as you can't un-hash it to use it.

Posted: Thu Aug 03, 2006 10:38 am
by Benjamin
I mean use the md5 as a key, and set the database table up like this..

RecordNumber
Key (md5)
URL (data? serialized or whatever)

Then use the Key to pull the URL Data

Code: Select all

SELECT `URL` FROM `Table` WHERE `Key`='blah' Limit 1

Posted: Thu Aug 03, 2006 10:53 am
by Jenk
got ya.

Posted: Thu Aug 03, 2006 6:45 pm
by Ollie Saunders
I mean use the md5 as a key
There are better keys.
How can I shorten it so users could give someone a link to a search without it taking a whole page to send it?
Use shorter name="" attribs. Post an example of it at its longest and I may have more suggestions.

Posted: Fri Aug 04, 2006 12:51 am
by Ree
astions wrote:I mean use the md5 as a key, and set the database table up like this..
RecordNumber
Key (md5)
URL (data? serialized or whatever)
Just use search ID (RecordNumber in this case), no need for md5.

Posted: Fri Aug 04, 2006 12:55 am
by Benjamin
Ree wrote:
astions wrote:I mean use the md5 as a key, and set the database table up like this..
RecordNumber
Key (md5)
URL (data? serialized or whatever)
Just use search ID (RecordNumber in this case), no need for md5.
Yeah that would work.

Posted: Fri Aug 04, 2006 1:57 am
by shiznatix
ole wrote:
I mean use the md5 as a key
There are better keys.
How can I shorten it so users could give someone a link to a search without it taking a whole page to send it?
Use shorter name="" attribs. Post an example of it at its longest and I may have more suggestions.
The way I have my framework setup, the names of the fields are the names of the vars in the model class which are the names of the collumns in the db so changing them wont work. here is an example of a url (not at the longest it could be)

Code: Select all

?SortByLocation=true&SortByPrice=ASC&SortByDateAdded=ASC&ResultsPerPage=200&Action=Search&fkObjectId=1&
fkTypeId=1&fkCountyId=1&fkCityId=1&fkCityAreaId=1&Address=flagstert+45&PriceMin=4&PriceMax=3&fkConditionId=&
TotalAreaMin=54&TotalAreaMax=43&RoomsMin=345&PicturesOnly=on&Action=Search&=SEARCH
I am not so sure I like storing it in the DB and everything. seams to add another level of complexity that could get all messy. Another extra 2 queries (select then insert) on a very large table (it would grow fast as any change at all would add a new row). Maybe its not such a bad idea but it might work

Posted: Fri Aug 04, 2006 2:09 am
by Benjamin
I guess choose your battle. I think that storing it in a DB would be cleaner, granted there is overhead involved, but it's like you can either pass the URL back and forth between the client & server, which uses bandwith, + it can be modified, or just write a nice little class that tucks it away in a database where it is secure.

I don't know how your app works though, so I am just speculating. Just brainstorming, that's all.

Posted: Fri Aug 04, 2006 5:45 am
by shiznatix
I don't know how to do the math but if every type of search was finally done and so every option was in the database so I only had to do a select then how many rows would be in the db?

there are currently 17 fields. Some of these fields can have infinate possibilities (like addresses) but lets ignore that. If each one of them has on average 10 possibilities then I would have 17 ^ 10 options --- roughly. That math is almost certainly flawed but I can't remember how to do it. With that calculation I get:

2,015,993,900,449 rows in my db. And thats if I only use the main cities in Estonia, which totals 4. If I add another country like Latvia that number doubles.

I am going to say that storing it in the DB is not in my best interest.

I understand all the ideas but a long URL is ugly (but still best right now) and the storing it in the DB is just too much. I still think that some form of encoding would be best if you could get it down to a smaller string, like a easily reversable md5.

If I am missing something obvious here let me know, or if you have any ideas then thats always helpful too :P

Posted: Fri Aug 04, 2006 5:51 am
by Benjamin
Whoaa no I meant temporarily only for the session or something like that, maybe add a timestamp and delete the old ones. 8O Sorry for not being clear.

Posted: Fri Aug 04, 2006 7:16 am
by Ollie Saunders
shiznatix wrote:2,015,993,900,449 rows in my db
Just because there are that many possibilities doesn't mean they are all going to happen.

Code: Select all

?SortByLocation=true
use value of 1?

Code: Select all

SortByPrice=ASC
SortByDateAdded=ASC
use value of 1 for ASC and 0 for DESC?

Code: Select all

ResultsPerPage=200
This applies to all of the above actually: do you need to send all that data at all? Can't you just have default values and allow the user to override where necessary.

Code: Select all

Action=Search
is that necessary? Can't this be determined by the page being requested, e.g. search.php

Code: Select all

fkObjectId=1
fkConditionId=
Action=Search&=SEARCH
what are those?

Posted: Fri Aug 04, 2006 8:27 am
by Jenk
shiznatix will be using a page and/or front controller, thus action=<action> will be necessary.

However, to extend upon astions suggestion, a table for stotred searches would be like so:

Code: Select all

create table `searches` (
  `searchId` INTEGER NOT NULL AUTO INCREMENT,
  `criteria`TEXT
) PRIMARY KEY (`searchId`)
ENGINE=InnoDB DEFAULT CHARSET=latin1;
so when the user uses the search page, a unique ID is generated (my suggestion just uses auto-increment but you can use whatever) and the criteria the user entered is inserted into the table.

Then the link provided can be as simple as:

Code: Select all

http://www.example.com/index.php?action=search&searchid=1
With the logic pulling the search criteria from the searches table and using it to perform the requested search.