Serialize post and store it for later
Moderator: General Moderators
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
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- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
- shiznatix
- DevNet Master
- Posts: 2745
- Joined: Tue Dec 28, 2004 5:57 pm
- Location: Tallinn, Estonia
- Contact:
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)ole wrote:There are better keys.I mean use the md5 as a key
Use shorter name="" attribs. Post an example of it at its longest and I may have more suggestions.How can I shorten it so users could give someone a link to a search without it taking a whole page to send it?
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&=SEARCHI 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.
I don't know how your app works though, so I am just speculating. Just brainstorming, that's all.
- shiznatix
- DevNet Master
- Posts: 2745
- Joined: Tue Dec 28, 2004 5:57 pm
- Location: Tallinn, Estonia
- Contact:
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
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
- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
Just because there are that many possibilities doesn't mean they are all going to happen.shiznatix wrote:2,015,993,900,449 rows in my db
Code: Select all
?SortByLocation=trueCode: Select all
SortByPrice=ASC
SortByDateAdded=ASCCode: Select all
ResultsPerPage=200Code: Select all
Action=SearchCode: Select all
fkObjectId=1
fkConditionId=
Action=Search&=SEARCHshiznatix 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:
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:
With the logic pulling the search criteria from the searches table and using it to perform the requested search.
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;
Then the link provided can be as simple as:
Code: Select all
http://www.example.com/index.php?action=search&searchid=1