Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 01/22/2020 in all areas

  1. @gizmola, Thanks for the thoughts. All of this is definitely a journey, because as I sketch things out (and talk to people) I learn new things and that can change my design. Dealing with the unknown and not knowing how to design things until you successfully design thing is what makes all of this a challenge! I'll take what you and others have said above and try to come up with a design that is flexible, scalable, and that helps me retain customers and make $$$. Thanks.
    1 point
  2. Hey Saranac, You seem to be conflating a "transaction" which is a database specific term, with a single page application (SPA) or combined form. What you do serverside with that form is up to you. Ease of use, credit card/payment processing and the dangers and cost of fraud are a complicated witches brew of risk/reward calculations. First of all, I don't know what you know or don't know about payment processing, but just because you got a cc authorization doesn't mean you will ever get paid. Worse yet, you could get a chargeback, and if you have enough chargebacks, you might end up having your merchant account closed. Again, maybe you know this or you don't. I don't know what your content is, or whether or not there will be a high amount of fraudulent activity, but every online business has some. So, as to transactions, and to "best practices" for selling digital goods or memberships, these topics are unrelated. At its simplest, a Member in your system, as you stated yourself, is not equivalent to a membership package. Membership packages also have one or more related "entitlements". So no doubt you have a package described in the database somewhere, and when someone successfully subscribes to a package for a year, one would expect a database structure like this: package ---< member_package >-- member where member_package is a table that stores "member_id", "package_id", "from_date", "to_date". What are strategies for dealing with the system. Well one, would be to have the culmination of a successful payment process be the setting of the "from_date" and "to_date". Another strategy might be to also utilize a "status" column with mutually exclusive states like: pending payment active suspended for fraud expired In that case you create the row, and can then use "active" status to drive access (along with from/to). Regardless of the form you use, there is no benefit to wrapping the creation of a member row with the transaction processing. If a member fills out all their details and has payment processing issues, it behooves you to create the membership row and put them into "pending payment" state. This way you can see how many people had issues with payment processing at any particular period of time. That way you can reach out to people who for whatever reason drop out of the payment process. You have contact info to market to them, or entice them with discounts. And there is always the situation where your payment processor was rejecting everything and these are customers you have 100% lost forever without some record that they tried to subscribe. DB transactions are important from a mechanical standpoint and I highly recommend using them, but you can have multiple transactions in your processing ie (membership account + address) THEN (payment processing & activation) and these can be handled separately in your code. Once you have some identity information, it's valuable to continue to carry this along in your session rather than stubbornly demand that the behavior of your system should conform to your ideal "happy path" scenario where a user puts in all their identity information for their membership perfectly, and at the same time gets the payment information entered perfectly and receives authorization. A "member" row, should be decoupled from membership (which you already stated you understand and agree with) which should be decoupled from subscription(s) which should be decoupled from payment processing details.
    1 point
  3. Good luck to you on that Jayfromsandiego. Try to post on Stackoverflow, or any of our myriad competitors. I certainly hope you will, if only so that you will find after the time it takes for you to register on each community and (re)post your "question" then wait for a response that may or may not ever come, only to find your question closed or ignored, or with a similar response to those you got here. This forum has a longstanding tradition of acceptance and hand holding that goes way beyond vast majority of programming forums that exist. As your question boils down to: "Here's what I want, code it for me?" don't be surprised when you get responses like ginerjm in even more blunt fashion. Meanwhile, NotSunfighter decided to take you up on your challenge and coded you up a solution. And just to be clear, noone (perhaps with the exception of NotSunfighter, after having spent valuable time trying to help you) cares whether you quit this forum. We are all volunteers. ginerjm may have been blunt, but he's right. We can all code. The vast majority of the people who answer questions like yours are professional developers. We are here to teach and share, and sometimes to simply tell someone the truth. The best I can hope for you at this moment is that you take a good hard look in the mirror at your own attitudes and approaches, and as the old saying goes "Don't cut off your nose to spite your face."
    1 point
  4. Alternative model which allows multiple siblings jdev_nroll; jdev_sibling; +----+--------+---------+-------+-----------+------------+ +------------+----------+ | id | sname | ctclass | shift | ctstudent | dob | | sibling_id | elder_id | +----+--------+---------+-------+-----------+------------+ +------------+----------+ | 1 | Curly | 1 | 0 | N | 2007-01-20 | | 2 | 1 | | 2 | Larry | 1 | 0 | Y | 2010-12-21 | | 3 | 1 | | 3 | Mo | 1 | 0 | Y | 2011-02-22 | | 3 | 2 | | 4 | Peter | 1 | 0 | N | 2009-01-03 | | 4 | 5 | | 5 | Paul | 1 | 0 | N | 2006-12-21 | | 9 | 8 | | 6 | Mary | 1 | 0 | Y | 2010-09-20 | | 9 | 10 | | 7 | Jane | 1 | 0 | N | 2008-03-08 | | 10 | 8 | | 8 | John | 1 | 0 | N | 2006-10-04 | +------------+----------+ | 9 | George | 1 | 0 | Y | 2010-10-26 | | 10 | Ringo | 1 | 0 | Y | 2009-11-15 | +----+--------+---------+-------+-----------+------------+ SELECT a.id as sibling_id , a.sname as sibling_name , TIMESTAMPDIFF(YEAR,a.dob,curdate()) as sibling_age , a.ctclass as class , b.id as elder_id , b.sname as elder_name , TIMESTAMPDIFF(YEAR,b.dob,curdate()) as elder_age , b.ctstudent as elder_ctstudent FROM jdev_nroll a JOIN jdev_sibling s ON a.id = s.sibling_id JOIN jdev_nroll b ON s.elder_id = b.id WHERE a.ctstudent = 'Y' ORDER BY a.id +------------+--------------+-------------+-------+----------+------------+-----------+-----------------+ | sibling_id | sibling_name | sibling_age | class | elder_id | elder_name | elder_age | elder_ctstudent | +------------+--------------+-------------+-------+----------+------------+-----------+-----------------+ | 2 | Larry | 9 | 1 | 1 | Curly | 13 | N | | 3 | Mo | 8 | 1 | 1 | Curly | 13 | N | | 3 | Mo | 8 | 1 | 2 | Larry | 9 | Y | | 9 | George | 9 | 1 | 8 | John | 13 | N | | 9 | George | 9 | 1 | 10 | Ringo | 10 | Y | | 10 | Ringo | 10 | 1 | 8 | John | 13 | N | +------------+--------------+-------------+-------+----------+------------+-----------+-----------------+
    1 point
  5. And if a child has a brother and a sister (or two or more of any gender)? [edit] There's this method, but it doesn't show explicitly that there is also a relationship between Curly and Mo too. SELECT * FROM jdev_nroll; +----+--------+---------+-------+-----------+---------+-----------+ | id | sname | ctclass | shift | siblingof | elderof | ctstudent | +----+--------+---------+-------+-----------+---------+-----------+ | 1 | Curly | 1 | 0 | 2 | | Y | | 2 | Larry | 1 | 0 | 3 | 1 | N | | 3 | Mo | 1 | 0 | | 2 | Y | | 4 | Peter | 1 | 0 | | 5 | N | | 5 | Paul | 1 | 0 | 4 | | Y | | 6 | Mary | 1 | 0 | | | N | | 7 | Jane | 1 | 0 | | | Y | | 8 | John | 1 | 0 | 9 | | N | | 9 | George | 1 | 0 | 10 | 8 | Y | | 10 | Ringo | 1 | 0 | | 9 | N | +----+--------+---------+-------+-----------+---------+-----------+ SELECT a.id , a.sname , a.ctclass , a.shift , a.ctstudent , b.id as bid , b.sname as bname , b.ctstudent as bstudent FROM jdev_nroll a JOIN jdev_nroll b ON a.siblingof = b.id; +----+--------+---------+-------+-----------+----+--------+-----------+ | id | sname | ctclass | shift | ctstudent |bid | bname | bstudent | +----+--------+---------+-------+-----------+----+--------+-----------+ | 1 | Curly | 1 | 0 | Y | 2 | Larry | N | | 2 | Larry | 1 | 0 | N | 3 | Mo | Y | | 5 | Paul | 1 | 0 | Y | 4 | Peter | N | | 8 | John | 1 | 0 | N | 9 | George | Y | | 9 | George | 1 | 0 | Y | 10 | Ringo | N | +----+--------+---------+-------+-----------+----+--------+-----------+
    1 point
  6. I'm not concerned about it because it doesn't have to be. Like you said, you feel like it has to be a certain way. I'm telling you that no, it does not. It's something separate from this to consider doing, but one that I recommend. But if you do it then you'll simplify some of this problem. No, what you're doing is allow anonymous access. I'm saying allow authenticated but non-premium access. Give like 20% access for anonymous users to get people to the site. Allow 30-40% access, plus maybe a couple features, for authenticated users to get people to sign up. Allow 100% access for people who pay money. This here is some fairly basic economics about funnels. Let people ease into your site until they're comfortable with the idea of paying money; making it a single step of "30% access and you have to pay to do anything more" is a cut-off that is going to lose you customers. Allow unpaid access. Give people who are interested in your site another step they can take that doesn't require them to pull out their wallets. Because you're fixated on the whole "omg it's all at the same time" thing that I keep telling you it is, in fact, not the case. No. It's dumb, but it's not a sin. I don't see how what you're describing now is different from what you were talking about originally. Before you wanted to do everything "at once". Now you want to do everything "at once". It's the same thing, just different words. 10 concurrent users is nothing. It's unlikely to happen, of course, but when you have everything "at once" taking a long time then you have to care more. For varying definitions of the word "slim". Congratulations. But you're describing stuff that everybody does differently. And they do it differently for a good reason: because it works better. You aren't anywhere near a point where you can run A/B testing to discover for yourself what works better and what does not, so maybe set aside your own designs and take a look at what other websites do. Because they have done the testing.
    1 point
  7. Depending on your business needs, sure: you could do all of those at the same time. But you're approaching this like it's all-or-nothing. It isn't. You can create the user regardless of the transaction. You can record the order regardless of whether the payment goes through. Don't treat it like it's all one big operation that you have to rollback/cancel if any one step fails - make each part work in its own right, just like if the user was in control of each step.
    1 point
  8. I've not used any of the listed options. The couple API's I've worked on have just used Symfony since that's what I typically use for other applications. It's worked fine for me for the most part. There are various bundles dedicated to implementing REST API's that may be useful (ie, FOSRestBundle).
    1 point
This leaderboard is set to New York/GMT-04:00
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.