PDA

View Full Version : Database for Mac




xyzeugene
Feb 17, 2009, 06:24 PM
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



michaelsviews
Feb 17, 2009, 06:33 PM
MySQL

kainjow
Feb 17, 2009, 06:51 PM
SQLite might do. It's already built-in to the OS and is used by Core Data.

larkost
Feb 17, 2009, 09:15 PM
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.

xyzeugene
Feb 18, 2009, 10:41 AM
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.

lee1210
Feb 18, 2009, 10:53 AM
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

xyzeugene
Feb 18, 2009, 10:59 AM
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

SQLite might do. It's already built-in to the OS and is used by Core 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.

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

plumbingandtech
Feb 18, 2009, 11:33 AM
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.

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.

xyzeugene
Feb 18, 2009, 12:38 PM
I haven't tried yet but this may address it:

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

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.

lee1210
Feb 18, 2009, 01:04 PM
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

Aea
Feb 18, 2009, 01:33 PM
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.

xyzeugene
Feb 18, 2009, 03:28 PM
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.

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.

Aea
Feb 18, 2009, 03:37 PM
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.

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.

plumbingandtech
Feb 18, 2009, 03:39 PM
I haven't tried yet but this may address it:

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

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!

3) Call MySQL and discuss licensing with them.

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.

Aea
Feb 18, 2009, 03:42 PM
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!

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.

GorillaPaws
Feb 19, 2009, 11:22 AM
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 (http://basetenframework.org/).

Thom_Edwards
Feb 19, 2009, 12:46 PM
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...

ChrisA
Feb 19, 2009, 01:26 PM
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...

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

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.

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.

Thom_Edwards
Feb 19, 2009, 01:45 PM
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


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.

ryan
Feb 19, 2009, 04:30 PM
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.

dr-jerry
Apr 15, 2009, 08:11 AM
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 (http://www.oracle.com/technology/tech/macos/index.html) has released their database for mac ox leopard.

uaecasher
Apr 15, 2009, 08:23 AM
MySQL. Why? Google recommend it :D


Experience in database programming; MySQL preferred.

http://www.google.com/support/jobs/bin/answer.py?lc=youtube&answer=57658

larkost
Apr 15, 2009, 09:40 PM
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.

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).