Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About SaranacLake

  • Rank
    Advanced Member

Profile Information

  • Gender
  • Location
    New York
  • Age

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I have a column where I'm a little unsure of the best datatype to use... MEMBERSHIP_PLAN_PROMOTION - id - promo_code - contract_term - unit_price and so on... As I'm sketching things out on paper, for "contract_term" I was going to store values like: "1 month", "3 months", "1 year", and so on... Why? Because it is easier to read and instantly makes sense. However, in the table below, I determine the "contract_end_date" by taking the moment someone subscribes, placing that in "contract_start_date" and then using "contract_term" to calculate the "contract_end_date"... SITE_SUBSCRIPTION - id - member_id - membership_plan_promotion - contract_price - contract start_date - contract_end I had considered changing "contract_term" to an integer representing days, but then that creates other problems... - Days are harder to read, especially if I had a 2 or 3 year contract_term. (Who wants to read 730 days for 2 years, and what about Leap Years?) - Also, Days don't give you an even "offset". For example, I can more easily have my PHP read a "start_date" = #9/17/2019# and then use a "contract_term" = "1 month" and come up with a perfect offset of "end_date" = #10/17/2019# versus adding 30 days to #9/17/2019# and then - depending on the time of the year - possibly being off a day or so. Follow me? So how can I have a column that is easy to read, and yet also makes calculations easy as well? Most likely, I will just have a few choices (e.g. 1 month, 3 months, 1 year) but obviously I want a design that can grow as business needs change.
  2. What is the latest and greatest way to hash data in PHP?
  3. I am working on a website which sells various content, including books/guides in an online format. A lot of people - including here - have stated that they wouldn't make a purchase on my site if I didn't also offer a PDF version of books/guides. (I guess more people read offline than I do personally?!) Right now, I am working on the ecommerce portion so people can browse a catalog, choose a book/guide, add it to their cart, and check out. (Just your textbook ecommerce metaphors.) After making a purchase, when someone logs in, then they can navigate to a gallery which contains thumbnails representing all of the books they have purchased. And by clicking on a given thumbnail, they will be taken to that particular online book which is a series of linked web pages protected from outsiders behind a paywall. I am comfortable with all of this, however I'm stuck on what to do with the PDFs... First off, when someone is in the Product Catalog picking out books and guides, should I give them the chance to specify if they want a PDF version, or should I just give everyone that buys a book/guide both access to the online book/guide PLUS the PDF version as well? Next, for customers who get a PDF, how should I deliver it to them? Do I make the PDF available when they navigate to their online book? Do I build a second gallery which only shows PDFs that have been purchased? Do I leave links to the PDFs up indefinitely, or should I just offer a one-time download? And if so, how would I go about that? In summary, something that seems so simple actually is very confusing the more I think about it. This is probably because I have never bought online books or PDFs before and so I don;t have any examples in my mind to go off of. Could definitely use some advice here, and am hoping this won't be as difficult as it currently seems?! Thanks.
  4. My point was that in the context of my e-commerce tables (i.e. what I listed above) the goal is to identify the ProductID and the unit_price for each product the user wants and to put that info into the ORDER_DETAILS table. User is buying... 1 @ Premium Subscription, 2 @ "How to become Rich" Books, and 3 @ T-shirts. And that info comes from your "main" PRODUCT table as you described above. All of the other things related to different product types can be stored in the related product-type tables.
  5. In the tables below... CUSTOMER --||-----0<-- ORDERS --||-----|<-- ORDER_DETAILS -->0-----||-- PRODUCTS Would you agree that what is really important in the PRODUCT table is a way to uniquely identify the product (ProductD) and to have a description and current price for it?
  6. I wouldn't be here if I didn't think there were people here smarter than myself - I'm talking to one now. But, yeah, that is also why I'm being a nervous-nelly and being skeptical of advice I take and decisions I make. Fwiw, I am *very* confident in what I have designed so far, just wish it wouldn't have taken me years to come up with?! If I can just get my e-commerce module done, then I'm home free and get "go live" and face the larger challenge which is, "is anyone willing to part with their $$ to buy what I'm selling?" Film at 11... 😎 Yes, I understand and agree. But this circles back to my challenges with design... I'm not always 100% certain what I need (or want). Most of the time I have a "vision" of what I want, but sometimes I'm not sure how things work in the real world or what others commonly do or what makes good sense, and so I end up with questions like today. I'm trying my best, but this stuff is complicated!!! ☚ī¸
  7. I agree other than I have made a long career of working for large companies that had poor design and they pay the price the rest of their lives because it is less painful to keep duct-taping crappy design than pull the plug and start over and do it right. Since I am a company of one, I fear really fubar'ing my design and never being able to recover. But I get your gentle "Analysis Paralysis" *hint* 🙂
  8. So the "type" helps your application to know where to do an INSERT? And are you saying that there would be a one-to-one mapping between the PRODUCT TABLE and say a THING_1 table or a THING_2 table?
  9. Alas that is the tricky thing about pouring concrete... Are the footings (and hole) "close enough" to where they should be, or am I gonna be crying when I realize my foundation/driveway is insufficient?! I see your point, but it's a fine line...
  10. So you aren't linking the tables with keys?
  11. I am trying to lay out table for an ecommerce site that sells both products and services. In a simple ecommerce site, you would likely have tables which look like this... CUSTOMER --||-----0<-- ORDERS --||-----|<-- ORDER_DETAILS -->0-----||-- PRODUCTS My problems is that for PRODUCTS, I have to connect to things like Online Subscriptions, Online Books, and then traditional items like Paper Books and T-Shirts. I am thinking that I almost need to use a supertype/subtype for PRODUCTS, but that seems rather complicated to do in MySQL or any database for that matter. Good designs should be simple, but it seems that the nature of what I am selling requires a more complex solutions and I'm not quite sure how to tie in my own table structures to the PRODUCT table so people can purchase products and services all at once?!
  12. So as the customer shops, I would just store the items they choose and the quantities in the $_SESSION? So at what point do you create an Order and populate the Order table? It wouldn't make sense to do that as a person is still shopping. I guess when they click "Proceed to Checkout" I could create the Order record then. But is there any harm in waiting until the click "Process Payment"? I guess one benefit of creating an Order record and child Order_Details records once they click "Proceed to Checkout" is that it is similar to having a persistent Shopping cart. What do you recommend?
  13. Let's say that I have a standard e-commerce setup with the following back-end table structure... CUSTOMER --||-----0<-- ORDERS --||-----|<-- ORDER_DETAILS -->0-----||-- PRODUCTS This may sound dumb, but I'm trying to understand how actions that the user takes while shopping would map to the back-end tables. For instance, when would I start populating these tables? Would I start populating the tables as the Customer is adding items to his/her shopping cart? (Or do I need extra tables for that?) Or would I populate all of the tables at the very end when the Customer submits the order? Or somewhere in between, like when he/she chooses to checkout? I buy thousands of dollars a year on e-commerce sites across the Internet, but that doesn't mean I necessarily understand all of the inner-workings of what happens behind the scenes! Can someone help me get a better grasp on all of this?
  14. Those would work, but I just have this new sense to use the word "entitlement"... 🙂 If I had to split hair, I would say that "entitlements" apply more to features. As in, "Which system features or functions are you entitled to use?" (Being able to modify a post a week after the fact or seeing a member's IP address or banning a member are all "entitlements", i.e. privileges, of an Administrator.) A MEMBER has a SUBSCRIPTION to a MEMBERSHIP_PLAN By purchasing a "Premium Membership", that MEMBERSHIP_PLAN has ENTITLEMENTS to the following SITE_FEATURES (access to archives, access to premium content, ability to message others, etc). On one hand it is all semantics, yet I think "precision" in language is essential to any well-designed system.
  • 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.