Everybody! This is important. In a few days, these forums will be moving over to using the totally sweet Discourse platform. To ensure this migration happens smoothly with no loss of content, these forums are currently in a read-only mode. I do apologize for the inconvenience.

There is never a good time to turn the forums off for an extended period of time, but I promise the new forums will be a billion times better. I'm pretty sure of it.

See you all on the other side in a few days, and if you have any (non-technical) questions, please e-mail me at kirupa@kirupa.com. For technical questions, try to find a tutorial that corresponds to what you are looking for and post in the comments section of that page.


Results 1 to 4 of 4

Thread: Calling all database/cms/backend PROs...

  1. #1

    Calling all database/cms/backend PROs...

    Ok, I need to make a customer database system, and i'm not sure where to start.

    Right now, the business is doing all their customer management using paper and files, and they want a computersed system. Just to give you an idea, they're a suit-hire company, and they loan out about 1200 suits per week. They need something to keep track of customer details, suit details, checkout and return dates, etc, etc, etc... My main concern is that the database will be massive...

    I'm thinking PHP+MySQL, cos thats all I know Plus, being web-based would be good, since the other stores could use the same database, but that's just a though.

    I'm totally newb to anything other than PHP+MySQL... but ive heard of other stuff like oracle and stuff...

    Any advice or suggestions would be appreciated!

    Thanks in advance.

    I think you should visit my site.

  2. #2
    home cooking is killing the restaurant industry
    Moved to Server-Side
    There are only 10 kinds of people in this world:
    Those that might know ternary, those that do, and those that don't
    Say NO to DRM.

  3. #3
    You'll be OK with PHP+MySQL, but look at things like transactions and InnoDB.

    With any business where money's involved, you want to make sure that you either update the database, or you don't - transactions will allow you to make sure you don't fail in the middle - for example, updating a client record that an order has been placed, but not updating the store record.

    InnoDB also gives you things like hot-backup, row level locking, and a bunch of other tools you'll find very useful when dealing with money.

    I wouldn't worry about the size, though. 1200 suits per week = 62000 rows per year (assumes 1 row in some order table for each order). The good news is that MySQL will work fine up to millions of rows, as long as you write your queries correctly (efficiently).

  4. #4
    Oh, ok. Thanks for that JustJeff Much appreciated.
    I guess I'll just stick to PHP+MySQL.

    Good to know MySQL should be fine with millions of rows. If it makes any difference, the host I'd be using have Dual-P3 1GHz CPUs. Could you explain what you mean by 'efficient' queries? I'll probably just be using SELECT, INSERT and UPDATE...

    Also, what's this InnoDB? I had a look at the site, but was a little dissolutioned... If it's for backing-up, the host does weekly tape backups anyway. I doubt they'd be needing to do money transactions from the program - just record keeping (if that's what InnoDB is for )

    Thanks again for your info

    I think you should visit my site.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

Home About kirupa.com Meet the Moderators Advertise

 Link to Us


Copyright 1999 - 2012