SaranacLake
-
Posts
648 -
Joined
-
Last visited
Posts posted by SaranacLake
-
-
17 minutes ago, kicken said:
I generally find the best thing to do is just create your tables and start working. You'll probably make a mistake/forget something in your initial table design but that's fine. You catch it while you're writing the code and then update your database as needed.
There's a point at which trying to plan ahead become counter-productive. You spend far too much time trying to anticipate everything you'll need/want and either make things overly complicate or still miss something anyway. So instead just put in the basic stuff you know for sure you'll need and then let the design evolve as you work.
All good advice, but I still worry...
QuoteI generally don't even bother with indexes outside of the primary key / foreign keys until I have something mostly developed, tested and working. That way I have a better understanding of what my actual queries are rather than trying to guess what they will be early on.
Good point.
Yeah, that is sorta what I was hinting at in my OP - that hopefully having to change indexes or even keys after you go-live isn't the end of the world. In my mind, what is the most important is that you capture the right data and have the right relationships.
For example, if you don't store "Order History", then later on you can't re-create it out of thin air?! And if you didn't have an "Order Details" table, but instead hard-coded 10 slots in your "Order" table, assuming no one bought 11 items, you would be safe, BUT you'd have a real mess to clean up later on!!
QuotePretty much every mistake can be fixed, some may just take longer or be more complicated than others. Most of your mistakes will probably be minor like "Oh, I should save this too" or "This should go in a different table" or "Maybe I should have an index here". You'd be hard pressed i think to make any mistake that I'd classify as "fatal".
Let's hope you are right about the "fatal" part!!!
QuoteBottom line, don't worry about mistakes and trying to get things right the first time. Spend more time actually working the problem so you know what you need rather than trying to think of everything first. Don't be afraid of re-factoring things later on, possibly multiple times as your understanding of things improves.
Well, hopefully i am at that point in my design where all of this is true. (Although I did find one problem area last night that I need to quickly re-work, but other than that, I think my database design is solid...)
Thanks!
-
8 hours ago, requinix said:
- System takes Shopping Cart details associated with PHPSessionID and links them to the new Member record
Do you care about storing shopping carts with an account? Some sites do, some sites don't. If you don't care then you don't have to do that step.
I have designed the "shopping cart" to be a database record regardless of whether a person a first-time shopper and doesn't have an account, or the person is a repeat customer and has an account. (I think most people just use cookies, but I've never really liked or undestood using cookies.)
So the moment a person chooses "Add to cart", things should get written to the database to provide some permanency.
8 hours ago, requinix said:Look at your process this way:
If a worst case scenario was to happen between any two steps, would your process be able to recover gracefully from the failure? Will you lose any information? Will the data in your database be incomplete or otherwise corrupted?
For example,
- System runs the payment - System hopefully gets back a "success" message from Payment Processor
One potential worst case here is that you submit a request to your payment gateway but the system blows up before it can receive the successful response. What would happen with the plan you've described? What should happen?
But be careful: I've chosen a particularly devious scenario for you to consider. The answer may surprise you.Well, the process I described in my OP was "piecemeal", and I chose to create the Member record first since it is a parent table that kind of drives everything else, so I didn't want to lose that, plus I need that before I can add things the Order and Order Details.
I could wrap the entire process in a database transaction, but then the question becomes, "Do you ant an all or none approach, or is it better to at least capture some info like creating the Member record?"
I'm not sure of the best answer to that.
Sounds like you have some thoughts...
xxxxx
-
This is part PHP, part MySQL question, but since I'm more interested in the process-flow, I'll ask here.
I am ready to start coding the e-commerce module of my website, which features mostly paid subscriptions.
Do the below steps sound like the correct sequence to do things in...
- Anonymous shopper adds subscription to Shopping Cart - Shopper goes to check out - Shopper completes checkout form which includes setting up the account and entering payment details Now for the important stuff... - System takes Shopping Cart details - which include the PHPSessionID - System creates Member record - System takes Shopping Cart details associated with PHPSessionID and links them to the new Member record - System creates Order and Order Details records - System runs the payment - System hopefully gets back a "success" message from Payment Processor - System activates the Member's account
How does that sound at a high-level?
Really what I'm trying to validate is if I should create the Member record 1st, then create the Order records 2nd, and worry about the payment last.
(Originally I was going to run the payment first, but I'm thinking it's better to capture the anonymous shopper's details in a Member record and Order records first, because even if the paymnt fails, you want something to work off of - like reaching out to the person and getting another valid payment.)
Thoughts?
-
So I am reviewing all of the pages and pages and pages of ERDs that I have, and hope to start building things in MySQL tomorrow.
Those of you who know me, understand that I'm terrified of making some gigantic mistake on my website, and so I often tend to fret longer than necessary?!
In abstract terms, where would you say people most commonly get into trouble when building databases from the ground up?
Or put another way...
What kind of database design mistakes tend to be "fatal"?
My hope is that as long as I've included all of the necessary tables, and as long as I have things normalized (or denormalized where necessary), that everything else should be relatively easy to fix - for example changing data-types, adding/removing a few columns, changing indexes, etc.
Thoughts on this?
-
-
1 hour ago, requinix said:
More precisely, the query analyzer will only use an index if the first N columns in it are included in the query.
Given indexes (columnA), (columnB), and (columnA, columnB),
SELECT * FROM table WHERE columnA = 123
could use the (columnA) or (columnA, columnB) indexes.
SELECT * FROM table WHERE columnA = 123 AND columnB = 456
could use the (columnA) or (columnB) or (columnA, columnB) indexes - and the last one is probably best.
Okay, good to know.
1 hour ago, requinix said:There's more to it than just about being "common", but that's a decent starting point.
Okay.
1 hour ago, requinix said:Point #1: An index takes up disk space to store the data.
Point #2: Each index slightly reduces performance when making changes to table data because the system has to update its indexes.
Point #3: (order_id, product_id) and (product_id, order_id) are mostly redundant.Conclusion: I don't think there's enough reason to create both.
Addendum: Actually it kinda depends on the data. But mostly I'm trying to discourage the "moar indexes moar columns" mentality.
That being said, and knowing that I will be querying on Orders and Order Details, and knowing that I need a FK on Order_ID and Product_ID, then it sounds like you are suggesting that I create one index on {Order_ID, Product_ID) and then my second index simply on (Product_ID), correct?
...
-
Hello. I wanted to get clarification on something we discussed a few months ago regarding FKs and Indexes...
Let's say that I have a typical order system with these tables...
ORDER - id (pk) and so on...
PRODUCT - id (pk) and so on...
ORDER_DETAILS - id (pk) - order_id (FK1)(UK) - product_id (FK2)(UK) and so on...
A few things I recall you saying to me...
- MySQL requires an index on all FKs.
- Indexes work left-to-right, and so any column that needs to take advantage of an index needs to be in the 1st position when multiple columns are in the index.
- If querying by Orders is more common, then I would want a FK like this: (order_id, product_id)
- I would need another index for product_id.
Question:
1.) In order to create an index for the Product_ID FK, and to provide for possibly querying on Product_ID, could my 2nd index be (product_id, order_id)?
Having (order_id, product_id) and (product_id, order_id) indexes would help with my two FKs, and all me to query by either Order or Product.
This seems like the best of both worlds, without a lot of overhead from unnecessary indexes.
Thoughts?
-
9 minutes ago, maxxd said:
Specify the method in your form tag (method="post").
Told you I was rusty on things!!
So there is still a lot of application logic I have to figure out, but it sounds like upgrading to the HTML5 button tag should help me to address any situations where I need to have several command-type buttons on one web page, right?
And another advantage is now I can just have one form, right?
-
20 minutes ago, maxxd said:
You'll have to define "isn't working". The following works for me as expected:
My var_dump isn't displaying anything.
Then I rewrite my code, tried this, but when I click on a button I don't get any results...
<?php if ($_SERVER['REQUEST_METHOD']=='POST'){ // My code... var_dump($_POST); // Maxxd's code... $option = $_POST['option'] ?? ''; if ($option) echo "You chose $option<hr>"; } ?> <!DOCTYPE html> <html lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>Sample</title> </head> <body> <form> Select an option <button name="option" value="1">Choose me</button> <button name="option" value="2">Choose me</button> <button name="option" value="3">No, Choose me</button> <button name="option" value="4">No, Choose me</button> <button name="option" value="5">No, Choose me</button> </form> </body> </html> -
3 hours ago, maxxd said:
True. This would solve the issue. I want to say (though to be honest I'm not entirely confident in my memory so don't quote me) that some browsers have issues passing button and submit element attributes on submission? Like if you name your submit button and then check for that index in the $_POST array being set it doesn't always catch it - I want to say it's mostly IE, which probably doesn't really matter any more anyway.
I haven't actively coded PHP in nearly 5 years - which is a painful place since I am trying to finish the last 10% of a very complex code-base. 😞
I added a var_dump to Barand's code to try and undrstand what was going on, but it isn't working.
What did I do wrong?
<?php var_dump($_POST); // Added to show data associated with button click. $option = $_POST['option'] ?? ''; if ($option) echo "You chose $option<hr>"; ?> <!DOCTYPE html> <html lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>Sample</title> </head> <body> <form> Select an option <button name="option" value="1">Choose me</button> <button name="option" value="2">Choose me</button> <button name="option" value="3">No, Choose me</button> <button name="option" value="4">No, Choose me</button> <button name="option" value="5">No, Choose me</button> </form> </body> </html>
3 hours ago, maxxd said:@SaranacLake The reason your third form results are off is that both the buttons have the same name, and they're both submitted with the form. So the value of `which_choice_did_i_make` is overwritten and will always be 'Form4_Input2'.
Yeah, I came to that conclusion last night.
(This is probably why on a related page that I started working on a while back I broke things up into 3 forms on one web page.)
3 hours ago, maxxd said:The thing about it is, if you're using AJAX and JavaScript you can easily use one form - the onClick event tells the JS event handler which button was clicked, that information is put into the data array and passed to the PHP script. No hidden fields, one form, no page refresh necessary.
However, the way you're doing it, there's no way the hidden field can tell the PHP script which button was clicked - all the data is always submitted. Just the act of clicking an HTML button doesn't trigger any special actions that will bind a field value to a field (obviously this can be done with JavaScript, but it won't happen in plain old HTML).
Yeah, that's a bummer.
3 hours ago, maxxd said:Assuming my memory is as bad as it seems to be these days, Barand's suggestion is the way to go for you - check the value of the button element name in $_POST and go from there. This allows you to have one form, no hidden fields, with mandatory page refresh.
Okay, but why didn't my var_dump work?
-
I'm looking at the code I added onto @maxxd 's code, and I think the problem is that I have 2 hidden INPUTs, but apparently they don't get "paired" with their respective BUTTON, and so the code is always grabbing the *last* hidden INPUT which is not what I was trying to do!
*********************************************************
Stepping back for a moment...
Today I was just trying to get my head back into using Form submit buttons more like command buttons, so I could figure out how many forms I might need, and then use that information to finish designing this web page.
But I think what I am trying to do behind the scenes on this web page is actually fairly complex. And I am starting to think that I have come fair enough along on mocking up my new web pages, and I should just dive into writing all of the PHP logic behind them?!
There is no sense wasting time on a page like this - whether it be the HTML/CSS or the PHP when I am losing site of the larger busines problem that I am trying to solve, if you follow.
I just know that I feel even more rusty with my HTML/CSS, so I thought I'd mockup all of the pages in this last module, and then code the backend stuff, but I think I've come far enough along and at this point it would be easier to just follow my use-cases and code along various business flows if that makes sense?
-
I appreciate your suggestion, but to be honest, I'm not sure that is the best way to do things.
I believe NAME should be treated like a variable and VALUE as the value assigned to NAME.
You are in essence putting values into NAME instead of variable names into NAME.
In addition, I am looking at my particular case, and starting to think this is a lot more involved than I originally thought... 😞
-
I am soooo rusty on coding HTML and PHP... 😞
13 minutes ago, StevenOliver said:no no no..... all the values can be the same (they can all say value="Click Me").... it's the NAME which is what PHP looks for! And those are hidden from view from the browser. (Anyone can see it in browser source though, no biggy).
Well, to be more precise, I believe that NAME is life a variable name in the $_POST array, and VALUE is the value you put into that variable.
So if you have 4 INPUTs and they each had a different NAME but with them all having the same VALUEs, then as long as you didn't need to compare values, I guess that works.
13 minutes ago, StevenOliver said:The web visitor just sees a button with "click me" on it. But your php code will see what you named each button. Visitors will see what you put for the "value"
<input type="submit" name="movies" value="click me">
<input type="submit" name="advanced_users" value="click me">
<input type="submit" name="button_two" value="click me">True, but if NAME=MEMBERSHIP_TYPE then your approach wouldn't work if the VALUES={Silver,Gold,Platinum}
But what @maxxd did was slightly different, and I'm not sure why his modified code didn't work. (It seems that "Click Me, Tree!" never gets seen...
-
8 minutes ago, StevenOliver said:
As long as each button has a different name="somethingDifferent" then your PHP processing page (wherever you submit your form to) will do whatever you want.
But that is part of the problem, at least two of my buttons have the same value but should do different things, thus the reason for needing either separate forms OR hdden values that are of course unique.
8 minutes ago, StevenOliver said:Note that ALL "hidden inputs" in a form get submitted <input type="hidden" name="unique_name" value="likes_boats"> each time a button is clicked.... but your PHP processing page can decide what info it is going to use.
Maybe that is part of the code I modified above?
-
Thanks for the sample.
I modified your code, but when I click on the 3rd and 4th buttons, the results are off...
<?php if($_SERVER['REQUEST_METHOD'] == 'POST'){ print("<p>{$_POST['which_choice_did_i_make']}</p>"); } ?> <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Testing</title> </head> <body> <form method="post" name="firstForm"> <button id="whatever" name="click1">Click Me!</button> <input type="hidden" name="which_choice_did_i_make" value="Form1_Input1"><br><br> </form> <form method="post" name="secondForm"> <button id="whatever2" name="click2">Click Me, Too!</button> <input type="hidden" name="which_choice_did_i_make" value="Form2_Input1"><br><br> </form> <form method="post" name="thirdForm"> <button id="whatever3" name="click3">Click Me, Three!</button> <input type="hidden" name="which_choice_did_i_make" value="Form3_Input1"><br><br> <button id="whatever4" name="click4">Click Me, Four!</button> <input type="hidden" name="which_choice_did_i_make" value="Form4_Input2"> </form> </body> </html>So why aren't things working properly?
-
Can you please help me figure out the proper way to use hidden input values? (If I can feel comfortable with that, then using one form is less of an issue.)
Any comments on the snippet I posted earlier?
-
7 minutes ago, maxxd said:
OK - that clears up my confusion. Maybe it's my cynical nature, but I couldn't see someone not choosing the "upgrade at a discount" option after their account had expired.
Yep.
QuoteGiven that, if you're processing all of it using the same script I would recommend using separate forms on the same page, each with a single hidden field to denote which form the user is filling in (which option they've chosen). Just remember to make sure on the back end that the user is eligible for the choice they've submitted.
So I would just use something like...
<input id="upgradeNow???" name="upgradeNow" type="hidden" value="whatGoesHere???">
I don't know Javascript or AJAX, so I'll have to let my PHP script behind the web page do all of the processing.
Just out of curiosity, if you are suggesting using hidden form values, then why the need for 5 forms? (I don't mind, but just curious.)
-
Wanted to make a correction...
I sketched out this web page on paper a couple of months ago, and have been busy today coding the UI part. (As such, I'm a little rusty on the logic behind it.)
Upon reflection, I guess the "before" and "after" sections should logically be binary...
If you land on the page before your due date, I'll still show both sections, but the "after" section's buttons (and thus forms) will be greyed out since they don't yet apply.
If you land on the page after your due date, I'll still show both sections, but the "before" section's buttons (and thus forms) will be greyed out since you missed your chance!
Earlier I should have said that I need to show both sections to get people to see the benefits of renewing/upgrading early.
My bad!
-
23 minutes ago, maxxd said:
I guess I'm getting hung up on why the first two options you describe show up on the same page as the last three. You say the first two are available to users before a certain date, the last three are available to the same user after the certain date. So why do you ever have all five choices on the same page?
To show the user the "before" and "after" scenarios, and encourage them to renew/upgrade early.
If you didn't see that the prices were going up, why would you renew - let alone renew early?
QuoteAll that being said, I'm not privy to the business logic and that will dictate how you handle the situation. I'm assuming in my comments that you're handling all the possibilities in the same form processing script, but that's not necessarily true - this means you can set it up in a way very different than the one I'm thinking of and describing.
Yes, I display forms and process forms all in the same script.
QuoteThe big takeaway is there's really not a difference. Your user will more than likely not be able to tell if there's one form on a page or a million. It really comes down to how you process the submitted data and how willing you are to have similar or related code in different places.
Okay, so there are no real downsides from a PHP standpoint... (Personally I like things compartmentalized when it makes sense.)
If I go with fewer forms, could you please refresh my memory how you use a hidden field to denote which button (e.g. "Checkout" #1 or "Checkout" #2) was chosen?
What is the HTML or PHP I'd need?
And are there any special security considerations that I need to factor in using that approach?
Thanks!
-
4 minutes ago, maxxd said:
Sorry, yes - of course you need a to know which option the user has chosen. So if you're doing it with a button per option then perhaps hidden fields on separate forms on the same page could be the best way to go.
Well, if I use hidden values for each button, then in theory I could have 5 buttons in one form, right?
When I mocked up a similar page earlier this summer, for simplicity, I just created 3 forms since I had "Checkout", "Checkout" and "Choose Free Gift" buttons with the last one going a completely different route, and the first two representing different products and prices.
That is why I was orginally think of just adding two more forms for the "before" section which will have "Renew" and "Upgrade" buttons.
4 minutes ago, maxxd said:The one thing I would recommend is you don't name several different buttons different things in the same form - as far as I know there are still some browsers in use that don't pass the name attribute of a button.
So in that case I'd need to use hidden values, right?
Which leads me back to my earlier question...
Scenario #1: I have one form, and 5 buttons each with a hidden field so my script knows what action to take.
Scenario #2: I have 5 forms, each with a single submit type button, and then it's a no brainer for my script to now what path to take.
Are those choices "six of one, a half-a-dozen of another" or is one way better?
-
15 minutes ago, maxxd said:
You don't have five forms - you have two separate forms with two or three options, respectively. Before the deadline, the user can renew or upgrade (1 form, 2 options). After the deadline, the user can select from three options (1 form, 3 options). That's pretty normal, really - there's no need for a hidden field as you should know prior to outputting the form whether the it's before or after the deadline for that particular user. The only thing you have to concern yourself with is the user's selection from the options available to the form presented to that user.
For the second section, 2 of the buttons read "Checkout" so at the very lest I need hidden fields.
For the first section since the labels are different, I guess I could have two buttons in one form.
What are the pros/cons of having multiple forms versus one form and multiple buttons with multiple hidden values?
-
Hello. I have a web page that has several operations on it, and I'm not sure the best way to design it.
This is a subscription page were a user can choose different renewal plans.
Before a certain date, the user can "renew" for a certain lower price (operation #1), or he/she can "upgrade" for a certain lower price (operation #2).
After a certain date, the user can choose from one of three plans (operation #3, #4, or #5).
The way I have things design for the "after" part is just creating a form for each one, so that when a user chooses one of them, then I can take the appropriate actions.
My question is this...
1.) Is it okay to have five forms on the one web page to more clearly delineate each request/operation?
2.) Or should I create one form, and then assign a hidden form value to each button so I know how to handle the selection?
-
On 5/22/2020 at 11:20 PM, kicken said:
I've more or less stopped typing tags in at this point. It's inconvenient to not be able to but what ya gonna do.
For longer posts I usually compose them in notepad then when done move them over to the text area and insert all the quotes/code blocks/formatting using the appropriate buttons. More work, but make the post look right.
And it prevents you from losing precious thoughts!
On 5/22/2020 at 11:20 PM, kicken said:I miss the old text-only editor still.
What I have learned - the hard way - is that a [ quote ] tag near the end will often slurp up uncommented text at the very end - and code too - and once that happens you cannot edit things, which is stupid.
When I have a quote near the end, with text following it, I try now to cut the quote after it is in, add a few carriage returns before the ending text, then paste the quote back it, and usually that works, but not always, plus sometimes I forget and then get burned.
This is a pretty big bug in the forum software if you ask me.
-
P.S. The way this website converts [ quote ], and [ code ], tags to an object is a real FUBAR...
I had to completely re-type y last post because this is this site trashed my post. nd as you can see, the [ code ] tags are still not working?! *rolls eyes*
From Shopping to Checkout
in PHP Coding Help
Posted
Well, I have to think about that, and I suppose that is one reason I posted here...
There will be several tables that need to get populated in order for the checkout to reach a final state.
The question again is, "Should I make it all-or-none or allow a partial checkout and then allow the user to go back and try again?"
It seems to me that in the past n PHPFreaks, people encuraged me to create the Member record at all costs so that I had some way to reach out to people via email or whatever in case of a failed checkout. (I think that makes sense.)
And if I had to guess, I probably need to wrap things like "Order" and "Order Details" into a transaction, because you cannot have an "order" if you haven't been paid - at least not with my business model. Likewise, you cannot have a 'paid subscription if you haven't paid me, so I suppose any tables related to that should be in a transaction too.
But I welcome any thoughts from the PHP gurus here! 😉