Database for Mac

Discussion in 'Mac Programming' started by xyzeugene, Feb 17, 2009.

  1. macrumors newbie

    Joined:
    Feb 13, 2009
    #1
    Mac Peeps,

    I am developing an application in Cocoa, I need a heavy duty database so that can either be embedded or have get a copy of such database and have them install. My program will be commercially distributed by yours truly. The database should be able to scale if need be. Also can handle server size data ranging in the terabytes and on the other end be cheap enough for me to distribute to at student pricing.

    If you want to know what I am developing, its going to be software for forensic auditing-I am an auditor/programmer.

    Any suggestions?

    Thanks

    Eugene
     
  2. macrumors 6502a

    Joined:
    Sep 25, 2007
    Location:
    Upstate NY
  3. Moderator emeritus

    kainjow

    Joined:
    Jun 15, 2000
    #3
    SQLite might do. It's already built-in to the OS and is used by Core Data.
     
  4. macrumors 6502a

    Joined:
    Oct 13, 2007
    #4
    MySQL is going to limit you to either buying a developer license from them, or going GPL with the program. A better choice in that space would be PostgreSQL. It has a BSD license which is much easier to deal with for companies. It is also arguably better in some areas than MySQL.
     
  5. thread starter macrumors newbie

    Joined:
    Feb 13, 2009
    #5
    MySQL Fees

    I found this from 2005 - should not have change much. MySQL does't sound like a good option

    http://stackoverflow.com/questions/156026/mysql-commercial-license-costs

    I just spoke with a MySQL sales rep the other day, and I agree it's hard to figure out their fee structure. The best I could understand, MySQL requires an OEM agreement in order to bundle MySQL into a commercial product. I was told that to get an OEM agreement, a company has to purchase an annual support contract from MySQL at ~$10,000/year -- there was no mention of any percentage of the list price. The Enterprise version of MySQL is $899 per server.
     
  6. macrumors 68040

    lee1210

    Joined:
    Jan 10, 2005
    Location:
    Dallas, TX
    #6
    I guess since no one has mentioned it i will bring up PostgreSQL. The Postgres vs. MySQL vs. Oracle vs. ... will rage for ages like any other holy war, but it is free, and it sounds less encumbered than MySQL in terms of distribution, etc. I can't speak to the technical merits vs. MySQL as I have not used MySQL for anything non-trivial.

    http://www.postgresql.org/

    -Lee
     
  7. thread starter macrumors newbie

    Joined:
    Feb 13, 2009
    #7
    Good for a single user option, but if I were to try to scale it, that would be a major problem when workin with terabytes of data

    I think this may just be the answer

    http://www.postgresql.org/about/press/faq

    I will structure my program(that I am designing) to have SQLite on a "Desktop" version and Postgres for my "Server" Version.

    Whats good about Postgres is that it can scale, be embedded, supports 64 bit computing, and has views.

     
  8. macrumors 68000

    Joined:
    Jun 20, 2007
    #8
    Hi.

    Are you going to require your customers to install postgres?

    I hope not. Maybe you mean on your server that you manage. That's fine. If you have postgres experience, if not just check out mysql, it is much more supported and has many more learning resources, of course if you need some feature in postrgess that only it has, then of course you picked the right choice, be sure though.
     
  9. thread starter macrumors newbie

    Joined:
    Feb 13, 2009
    #9
    I haven't tried yet but this may address it:

    http://www.macosxguru.net/article.php?story=20041119135924825

     
  10. macrumors 68040

    lee1210

    Joined:
    Jan 10, 2005
    Location:
    Dallas, TX
    #10
    Longterm it might be nice to allow users to host the DB on another, beefier server (if you're going to have TBs of data), and connect using your client on the desktop.

    -Lee
     
  11. Aea
    macrumors 6502a

    Aea

    Joined:
    May 23, 2007
    Location:
    Denver, Colorado
    #11
    I don't believe you need to license MySQL if you're distributing it unmodified as a separate thing.

    SQLite should be a good choice, but with TBs of data, why will you envision having so much data? You may need to do some file system based storage.
     
  12. thread starter macrumors newbie

    Joined:
    Feb 13, 2009
    #12
    I still don't know about mysql. They are not very clear on website. Unless you have some more info I am inclined to believe that they will charge $10K so I can deliver an embedded app.

    TB of Data - Corporate data stores usually have TBs of data. GLs, AP systems, Contractuals payments, revenue data, drug inventories - look at alot of the major frauds, they could have been caught with basic data analysis ie Enron with mark to market trading.

    I use to be in the Data management group of PwC (Pricewaterhouse Coopers-the largest auditing firm in the world ) , lots of my work has been in the WSJ my audittees include Freddie Mac, AIG, and etc. Ever wondered how auditors can make assessments about large public corps? Its not by sampling nowadays my friend - I investigate at 100% of transactions sometimes multimillion $ accounts are reconciled to the penny. The secret is mad database/auditing skills

    Now I work for US Oncology in the Internal Audit Dept. On a daily basis I analyze/audit 600 Oncology practices across the states. I work with massive amounts of cancer/financial data daily. I just want to break out and start my own thing.

     
  13. Aea
    macrumors 6502a

    Aea

    Joined:
    May 23, 2007
    Location:
    Denver, Colorado
    #13
    Well then I'm sure with that impressive resume you'd have enough money to :

    1) Pay for the MySQL licenses if you really do need to bundle it directly.
    2) Hire an Software Engineer or better yet a DBA (or both) that you can consult with on how to get that much data stored.

    And MySQL can do it easily, but it's the other operations on the DB that will need to be closely monitored.

    or even:

    3) Call MySQL and discuss licensing with them.
     
  14. macrumors 68000

    Joined:
    Jun 20, 2007
    #14
    Yah that might do the trick.

    Word of advice:

    Test that first, build a barebones app that has a form , view and save button.

    then test test test test (you prob. will have to add an import to get your massive data sets in) then send it to some friends and have some test.

    The last thing you want is a beta about to ship of your app that you have invested 9 months only to find some limitation of the db and the day before you were about to ship.

    best of luck! sounds interesting!

    Definitely do that too, they make deals, everyone does at that level maybe instead of 10K up front you may pay them a lower per unit cost.
     
  15. Aea
    macrumors 6502a

    Aea

    Joined:
    May 23, 2007
    Location:
    Denver, Colorado
    #15
    If this poster is even serious, yes, test and test. It may be an implementation detail for some but when you get large DB's that may need a lot of operations done you need to build from the ground up to support that.
     
  16. macrumors 6502a

    GorillaPaws

    Joined:
    Oct 26, 2003
    Location:
    Richmond, VA
    #16
    I like PostgreSQL because of the flexibility of their licensing (also they seemed to have greatly improved performance over the years). If you do want to go that route, you might want to have a look at BaseTen.
     
  17. macrumors regular

    Joined:
    Apr 11, 2003
    #17
    Just a thought...

    Why not develop your application so that it is not tightly coupled to a specific database vendor? Let your customers choose their database, based on their requirements and your recommendations after taking into consideration their projected needs. After hearing the scope of the work and data involved, I would think you would have the expertise required to be able to show that extra level of support and flexibility to potential clients.

    What if I was interested in your application, but my company required Oracle due to IT policy? Oh, you only support Database X? Sorry...

    Just a thought...
     
  18. macrumors G4

    Joined:
    Jan 5, 2006
    Location:
    Redondo Beach, California
    #18
    I've done that and then you end up with not only poor performance but have to ue only the lowest common sub-set of features.

    For example if your data is geographic it is very nice to be able to use a DBMS that allows you to define types and operators and function over those types (PostgreSQL and others can do this) then you can query for "All points within a bounding polygon".

    I would only go the generic interface route if there is good reason for that. You will have to give up many good features to gain the flexibility

    I've actually seen this problem. We did a preformance test using "only" 100,000 rows. It turns out such a small table caches in RAM and the querries are always fast but with 100M records it did not cache and was unacceptably slow. On another project we tested using 3 or 4 clients. We found MySQL to be very fast, but later with over 12 clients performance crashed do to the why MySQL handles locks.

    If you want the project to "scale" you have to test with worst case scenarios. Not small toy test cases. You do not have to write code to do the tests. Just some SQL from the command line and some scripts and a stopwatch.
     
  19. macrumors regular

    Joined:
    Apr 11, 2003
    #19
    That is an excellent point regarding the lowest common denominator as far as features are concerned. I thought of that while I was posting, and I certainly don't disagree with your example to support your point.

    I then thought, though, that in the case of the application the OP mentioned, it seems that the db will simply be a storage container and the application would be doing only basic SELECTs and then do the data analysis heavy lifting. He never said that specifically, but that is how I imagined it. Perhaps I think that way because he only mentioned size requirements, and not any specific feature of a particular SQL flavor. I would be interested to see what he had to say about that.
     
  20. macrumors 6502

    Joined:
    May 17, 2002
    Location:
    Denver, CO
    #20
    To answer the OP question(s), it seems a little out of sorts that users who are going to be processing "terabytes" of data would expect to be able to do it on your average Mac at "student prices". In my experience applications that need to process that much data are going to be running on dedicated, higher-end (or clustered) hardware and administered by database professionals. As such, database licensing fees aren't usually a huge issue because the database software is already in place to support other applications. Given all that, it might better to either focus on a true desktop application where you could get away with using an embedded database like SQLite or a more enterprise type solution where a user/customer would have to have Oracle/MySQL/Postgre/etc. already in place.

    Hope that helps.
     
  21. macrumors newbie

    Joined:
    Apr 15, 2009
    #21
    Oracle

    While I do agree with previous poster to loosely couple your database with your application, or even with os (I do java) It may be worth mentioning that oracle has released their database for mac ox leopard.
     
  22. macrumors 65816

    uaecasher

    Joined:
    Jan 29, 2009
    Location:
    Stillwater, OK
  23. macrumors 6502a

    Joined:
    Oct 13, 2007
    #23
    You do need a license for MySQL if you are not going to license your software under GPL. Last time I checked (admittedly a while ago) the MySQL ODBC connectors were all GPL licensed, so if you are going to link to them, you need to be GPL (unless you have bought a license).
     

Share This Page