Usually you don't include the password for the sa-account in the question. Usually we also frown on "SELECT *", and weirdly, you use a "using" clause for the connection but not for the disposable command.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
I have a product that offers a small lead management system. The architecture of product is simple so far. I have tables called 'companies', 'users', 'leads'. Users within a company have CRUD rights on leads. Now companies want their agents to have rights to operate leads. So we can ask companies to add their agent as a user within the company but there is a problem. Each user needs to have a unique email to register. So if one agent serves 5 companies they can't be added as a user by each of them. What should be the ideal way to handle this.
Thought of having separate database for each company so that problem of unique email is resolved but I'm not sure how to manage multiple databases for updates
I have both guest and members cart options at checkout.
Everything works fine.
I store my cart items in a session currently.
Users can log in or have a guest cart.
Guests cart userids are referenced by the current session id.
members can login and their carts are referenced by their usersids from the database.
The problem is, the session expires after a certain amount of time and so the cart items are lost and the user has to start again.
On doing some research I have found that after the user logs in, I can store his user id in a cookie and I can specify how long that cookie lasts for which is ideal!
I am thinking of changing the code so that I store the items added to the cart in my database tables and simply reference them with the user id ive stored in his cookie.
That way He can shop for ages and not lose his cart and I can send abandon cart emails etc...
What does everyone think about this?
Please note I am not seeking security advice here.
Let's discuss this in a bit proper detail with the application of performance, security and regulations.
You can store anything that is publicly available on your website, and does not contain any personal or identifying information in a cookie. The reason for this is, that a user might be accessing your website from a public machine or PC and that data might be tracked or stored. Next, for a session you can use this storage to store any information that might identify (because, hey, that is what a session is about, right?) the user and help your website perform an operation quickly—without having to query the database again just to find out their user id, or email address. Do remember that on most frameworks (if not all), session data is sent to the client too.
Now as per regulations, make sure you are requesting permissions from the users to store the cookies on their machines—European regulations require you do that, and then there is GDPR, and etc. etc.
Now as for the database part, this space is expensive and filling it with the content that does not help you in anyway—let us for a moment ignore the analytics, user studies, machine learning for recommender systems, etc.—and they will only take away the space that you should pay for the content that helps you generate some business profits.
What I would recommend here is, store the cart information in the cookies, just reference the URLs of the items they want to purchase. This way, the cart information will be stored locally. This will decrease the overall load on your web servers, and will not cause extra charges in the database storage as well since your users will be storing their interests locally and won't add a cart option in database, and forget it leaving there forever.
In this approach, of course you will end up showing what John wanted to purchase to Johanna as well, and that can be fixed by storing the session id(! Remember, store only the session id not the user id and then verify that the sessions are same for the user—which can be done by some backend algorithm to check if user ids of the sessions are the same )
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
Depending on how dynamic the table is (I would think Ports would be rather static) I would brute force the categories into separate table(s) and either use Richards pivot or a monstrous view with 30 left outer joins. Then when you get a new Ports just run the brute again to parse the Categories.
Never underestimate the power of human stupidity -
I'm old. I know stuff - JSOP