I figure that this should be possible, as it is a requirement asked by my supervisor. There are a few types of accounts, one of them is a 'company' account which should allow anyone in the company who has these credentials to log in at the same time.
Now my question is, how do I store temporary data like:
(this is fictive)
shopping carts, keeping track of wizards,...
I suppose that I'll have to store this in the database?
What would be my best option. Link it to the unique session id?
Yes, you can store sessions in your database if you like. A nice way to do it, is by creating a sessions like table that stores states. Therefore, if you have a cart, you can have a cart table that represents what products the cart has and replay that after a user logs back in.
Session information isn't based on your account-system but on the system of the visitor (cookie). Unless you want all information to be shared across all users logged in on the company account (which I doubt) you shouldn't have to store any of the information in the database.
To store the data you can simply keep using session (as I suppose you already do for the 'normal' account.
Related
I create an online store website
when user add some product to cart i save this information in session (if user not logged in)
and
when user logged in and select some product i insert them into table
is this true way?
can i store all information of user selected product in session?
I think the best way to go in this case is not using the database at all, but use cookies instead.
PHP Cookies
This way you don't have to query the database, and all data will be saved on the computer of the user. This will also keep the information for the people who are not logged in. Which will be more user friendly.
Better to store items in session (for both visitors or logged in people)
Only needeed of store them is only when they intend to buy the product.
On visit (even if user is loged in or not) you donot have to store them in db.
Further, use db only for values you have to refer in future.
I'm developing a shopping cart for a website, and was wondering what way should I store the product id after the user has clicked on the "Add to cart".
Should I store them in a session -- Such as
$_SESSION['cart'][$productid]++;
Would this put strain on the server under load? Or is this the best way of doing it?
Or should I create a temp database table, store the information in there, and remove after order has been processed?
I would store them in a database for sure, but not create a temp table each time. I would suggest you keep a table that has all the unfinished orders along with an identifier for the user.
This will last longer than a session, all it to be retained after a user has logged off and available after that user logs back in again. When then user is logged in, keep their identifier in the session.
Edit: While connecting to a database does consume resources, that is what database servers are made for. A connection to a small table uses next to nothing - I mean, you are probably executing a good number of queries just displaying your shopping cart. If you get to the point where your website can't handle the extra stress due to saving an odd row in a small table, you will be getting enough money from the sales to buy a bigger server :)
You should definitely use a database table to store the items.
Logged-in users will appreciate that they didn't have to grab all items again, if they come back after some time!
You can keep the information of the cart in the session, to get the information you need, but you should set new information in the session and in the database!
And then before checkout you should cross-check your information.
Another advantage is that you can keep track of what is going on in your shop!
You wont have any information if no one buys your items and you store the carts in a session.
I wrote a simple web app to let user input data as they walk around in a warehouse looking up products.
The database is a very simple one I created for the sole purpose of gathering some product data. They start the process by entering the location they are at the warehouse. There are multiple users, and I did not implement a login feature; the application is accessible by anyone on the local network.
I want to keep track of the location IDs that the users input, but I want to be able to distinguish data input by different users.
I need an identifier that will allow me to distinguish one user from another. It can even be different for the same user every time he connects to the DB or uses a different computer.
Is this possible?
You could save the session id I guess, but it's not very identifiable to a specific user.
It would however allow you to identify which actions were done in the same session.
Just remember to start your session first:
session_start();
echo session_id();
Maybe this way: http://php.net/session_id
And don't forget to init session: http://php.net/manual/en/function.session-start.php
I would make use of a unique session ID along with setting a unique User ID in the Session as well so both can be recorded. I do something similar with an application we use.
session_start()
$_SESSION['UserID'] == ? <---- Create you variable
You can read more here:
http://www.php.net/manual/en/book.session.php
Keeping track of sessions will also allow you to monitor active sessions, record active sessions in database, implement some basic timeout functionality if they are not active for a period of time, etc...
I'm trying to implement a "favorites" feature to my site and I was wondering on how to go about storing this data. What I'd like to do if possible is have the user favorite things and store it in the DB - that way I could use the data to personalize search results.
I'm also trying to have it so there is a smooth transition between favorites in a non logged in state to a logged in one (allow the user to save favorites anonymously but if logs in transfer/ask to transfer those to his account)
How would I be able to store this data for long periods of time? I'm currently using DB encrypted sessions and I was thinking of extending the session time or setting it to not expire. That would probably lead me to some security issues no?
I'd appreciate the help,
Cheers.
Well, if i understand, what you want is that a registered user can set "something" as a favorite, since this is a M:N relationship (strictly from a database point of view), i would recommend a table storing these relationships, i.e. Supposing you have a user and a topic table, the SQL would like similar to this:
create table favorite(user_id integer not null references user, topic_id integer not null references topic);
At least this is what most DB books will tell you to do. If you don't have a user table (i suppose you have one for that "something" you want to mark as favorite), you could just store the id you assign to the user whenever s/he logs into the system. Hope to have been of help.
Create actual users out of your anonymous sessions. Persist them in the database without login credentials and associate favorites or whatever else you store with their user ID. If they sign up before they clear their cookies, you just add their login/profile into to the existing user ID and all the favorites they've created are already in the right spot. One system for both logged in and logged out users, not two.
I am in the process of making a website that involves a shopping cart.
There are two major requirements:
The user experience guys want login/authentication to be the very last step in the entire work flow. The user gets to do all the shopping and is asked to login only at the time of checking out.
The shopping cart shouldn't expire(not even on browser close) unless the user (registered or not) does check-out.
In the above context, I have the following question with respect to maintaining the cart's state:
Should I go with file based or database sessions? Please keep in mind this would be for unregistered users. My apprehension is that I'll end up having lots of records in the database.
Another option seems to be to put the cart contents in an encrypted cookie, but then there's a size limitation on the cookie file.
What would you do in this case ? I would really appreciate your answers.
Tracking a user. Use a GUID
encoded into a cookie with an
nYear expiry.
Storing a Shopping Bag. You don't want to store the bag in the cookie, mainly due its possible size. This leaves the option of persiting it to a medium and retrieving it from the medium. Using anything except a database for this would be like going back in time, databases excel at storing and retrieving data.
Managing you Shopping Bag. Now, the
question of your schema, firstly, if
your going to be running queries
against the shopping bags in the
database (i.e. how many shopping
bags contain item x) you probably
want a traditional relational
schema. However this has overheads
in terms of inserting. updating,
selecting (and joining) and deleting
bag data (at some point you'll have
bags that will never be used again
but are taking up precious disk
space). With a busy site, this is a
fair few Traranactions Per Second,
but any database should be able to
cope. If you don't need to query
the shopping bags in the database,
then you can store it as XML. Just
serialize the bag and dump it into a
table, with the PK as the GUID as
stored in the users cookie. This
would be a lot faster than a
traditional schema, plus you could
always tear apart the XML in the
future if a requirment did come up
for a relational schema.
This is what we do (Xml Bag), and we have a million+ customer base.
I would go with database managed sessions over file managed sessions. Make sure you have a session timestamp so that you can eventually kill old sessions (if it's been 12 months, the shopper is possibly not coming back for the items originally in the cart).
Doing this with a database instead of files will make it easier to eventually expire the very-old information.
Note that the database session will only ever be valid as long as the cookie it's tied to on the user's computer. If the user comes back to the store from a different browser, they will not find their session. If two people are sharing the same computer, they will find each other's session. Hopefully no potentially embarrassing items will be in the cart...
Store in cookies the AnonymousSessionID, with which you associate a shopping cart in the database.
Then you'll have a scheduler task to erase anonymous sessions after some time (say, a day). This will keep your database clean of abandoned sessions.
If a user registers, you reassociate their shopping cart with their account permanently. If the users makes an order, you empty their shopping cart.
If you're using ASP.NET here's what I'm (about) to do:
use a Profile to capture the users email as soon as possible (to email them if they dont complete the order). you can enable anonymous profile properties that are persisted to the aspnet database even if the user hasnt actually truly registered.
stick an XML bag representing an order into session. This is persisted in the database with a regular identity ID.
store the ID of the cart in the ASP.NET Profile. that way when the session expires you can just reload it from the ID in the profile. this has the benefit that the user never sees the cart ID in a cookie and you can easily link records between the membership/profile database and the store you're using for your orders
(dont try to store the XML order in the Profile. i think thats asking for performance issues. but in theory you could i suppose)
With those specs I would go with a database based session state. But you should do some heavy reading on how session state is handled in your web server of choice. Since you want to be able to revive the state to the correct person.
I think you have some expectations to manage, or maybe you weren't clear on requirements.
The user experience guys want login/authentication to be the very
last step in the entire work flow. The
user gets to do all the shopping and
is asked to login only at the time of
checking out.
The shopping cart shouldn't expire(not even on browser close)
unless the user (registered or not)
does check-out.
Specifically, an anonymous, not logged-in user's cart being saved? That's madness. Ensure that's not an expectation and clarify it in your design documents.