I'm looking to create SQL database on my Mac and I was wondering what would be the optimal software I can create/operate it with.
Any advise will be highly appreciated.
Postgres
Postgres is a mature heavy-duty enterprise-quality database system. Postgres aims to implement the SQL specifications as closely as is practicable. Postgres is open-source and free-of-cost. Multiple companies sell professional support services. Conferences dedicated to Postgres occur year-round all over the globe including in Ottawa where the core contributors meet. The more I learn about Postgres, the more impressed I become.
There are different ways to install on a Mac:
The usual way is to run an installer provided as a courtesy by the EnterpriseDB.com company. For security, the installer creates a new Unix user on your Mac named "postgres" and creates folders accessible only to that user rather than your regular User account.
Another way to run Postgres is a unique configuration packaged as a Mac app, called Postgres.app, provided as a courtesy by the Heroku company.
MySQL & MariaDB
MySQL (and MariaDB) is a competitor to Postgres, and is quite popular. But MySQL pales in comparison to Postgres in my opinion, in regards to quality, robustness, stability, security, documentation, responsible gradual planned development, focus on safety of your data, openness, and more considerations.
The more I learn about MySQL, the less impressed I became. But MySQL is very popular. You will find many resources, books, and postings on MySQL. But its popularity eludes me. MySQL versus Postgres is like Linux versus BSD, the one seems superior in so many technical categories yet the other gets all the popular hype.
But no need to start a flame-war: check it out and make your own decision.
SQLite
SQLite is another open-source free-of-cost SQL engine. But as the name suggests, it is aimed at relatively small simple purposes. Apple bundles SQLite with both Mac OS X and iOS.
H2 Database Engine
If you are savvy with Java, you might consider the H2 Database Engine. Simple to get started with. Mainly aimed at embedding in an app, though you can use it as a database server. Though it lacks many server features, it may be a good way to get started.
Derby
Derby is another Java-based database engine for both embedded use as well as server. Originally a commercial product, later acquired by IBM and then donated to Apache as an open-source free-of-cost project. There have been some issues with heavy use in production, so research the current state of development. H2 seems to be a better choice over Derby, currently.
Firebird
FirebirdSQL in another open-source database, but I've no experience. Seems to have engaged a new wave of interest and development in recent years.
OpenBase
OpenBase is a commercial database server originally developed for NeXTSTEP/OpenStep (which evolved into Mac OS X that we know today).
Interbase
Another commercial server is Interbase by Embarcadero Technologies.
4D
4D (formerly 4th Dimension) is a unique kind of database server, originally developed on the classic Mac and lives today on both Mac OS X and Windows. 4D is special because it is a competent relational database server but has a proprietary query language rather than SQL. 4D is also special because it is integrated with its own programming tool-set that includes a visual form-layout development environment. Other development tools can access its data through Web Services calls (SOAP, JSON, etc.), plugins, and other mechanisms.
My view
My own choices for projects of late have been:
Postgres, for heavy-duty mission-critical purposes where preserving data is paramount.
H2, for lighter uses, and especially where portability is important. Being Java-based, it can run anywhere.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I would started a database project (Accounting Application) for now Mac version which will be available in AppStore.
For future might be on iOS, Windows and web base.
I need database app that don't need the database ported to other platforms just by changing the UI and other sources I able to port it, no need to touch the database.
I'm a bit confuse to choose a suitable database SDK or etc!
Ror example I can choose:
• SQL Server
• MySQL
• SQLlite
• FileMaker
• Cocoa SQL
Remember I need:
1- Something not to complicate and easy to use it on XCode.
2- Have a bit security on the file.
3- the most XCode user using it.
4- Price is no problem.
5- Unicode fully compatible.
For my situation, which one do you recommend.
I think you're approaching the problem backwards - first you should be deciding on what development and deployment platform you want to use, and then select the best database server compatible with that platform.
What I mean by this is that whether you're using SQL Server, MySQL, SQLite, or any other faceless database engine, that doesn't answer the question of how you're going to develop or deploy the application.
You also need to decide whether to write one application for deployment on all platforms, or if you're OK with rewriting the application for deployment on certain platforms. The only technology choices I'm aware of that will work across all the platforms you've mentioned is an HTML 5 web app (using Ruby, Java, .NET, PHP, or some other web development system) or FileMaker (using FileMaker Pro for Mac / Windows / Web deployment and FileMaker Go for iOS deployment). If you're OK with writing a desktop/iOS version separately from a web version, then you need to ask yourself how many versions you want to write. If you pick something like C / C++ / Obj-C, then you're going to need to pretty much re-write it for each platform you've mentioned (although you can port from iOS to OS X with less effort than the other platforms). If you pick Java, then you're set for web deployment, Mac deployment (although you can't distribute Java apps via the Mac App Store) and Windows deployment, but you'll need to use Obj-C or HTML 5 for iOS.
So in summary, the right approach is:
Pick your deployment target(s)
Based on that choice, pick your development system(s)
Based on that choice, pick your database engine.
If its for a single user application SQLite is probably the best option - its purpose built for embedded apptications. Its also portable between os types.
I'd second the recommendation of SQLite as a lightweight database portable to multiple platforms. But what do you mean by "fully compatible" with Unicode? See: http://www.sqlite.org/version3.html
It's hard to say what you need from your description, but from what I can glean, SQLite would be the logical choice. However, if you insist on actually having a database server, you should investigate PostgreSQL. It has a far more permissive license than MySQL.
I would advise you to pick a Database Management System based on your data management requirements rather than on your choice for other components of your system. In the end almost all of them support SQL. SQLite is a good choice for a portable client-only solution. SQL-Server, MySQL, Postgres, DB2 and Oracle are optimized for server-side transaction processing (lots of inserts and updates). Vectorwise, Vertica and MonetDB focus on analytical queries (e.g., statistical analytics on your data like group by). If you make a bad choice here you might face scalability/performance issues later which may be very expensive.
So pick your DBMS based on the anticipated usage pattern.
BTW: A License for an Oracle DBMS instance can easily go up to a couple of ten thousand dollars. So be careful when saying "Price is not a problem".
I'm wondering if anyone is currently utilizing Microsoft's Master Data Services? How you are utilizing it? Whether you find it useful? When you believe it would be useful? Thanks!
I have been working with MDS since it was first released as part of a feature pack for SQL Server 2008 R2. While MDS has some compelling features - most notably detailed data lineage, I am not confident in recommending it to clients yet.
My reason for this hesitation is the nature of the install and the tendendency to fail on upgrade or system change. I struggled mightily with the both the SQL Server 2012 RC0 MDS and the RTM installs. There are simply too many brittle aspects of the install (such as the hard requirement that the service be installed on a domain-joined machine and the need to install the Silverlight 5.0 SDK for the client to work properly). I also experienced flakiness in the the Excel add-in.
I see where Microsoft is going and I think the product will eventually be useful. Considering it's purpose (master data repository), MDS must be more 'rock solid' before I would use it in production.
We aren't using it currently in our office, however the presentation Microsoft did in town a while back seemed very interesting. I saw it as sort of a competitor to Oracle's OBAW warehouse. You've probably already looked at these, but Microsoft has a decent set of webcasts that cover how to install and use MDS out here:
http://www.msdev.com/Directory/SeriesDescription.aspx?CourseId=155
I'm anxious to see if anyone else is using it as well, we tend to have a hard time talking our management into letting us try these types of services without being able to point to other corporations that have successfully implemented said product.
We're just starting to investigate the use of MDS to support our consulting practice, specifically around data analytics and ETLs to deduplicate, standardize, and sanitize client data. It's probably just scratching the surface of MDS, but we were led to MDS initially for its inclusion of regular expression capabilities in SQL to transform free-form text data.
Before MDS/DQS, part of the sustainability / enduring-success of a custom database application was heavily dependent on one or both of the following items...
Having a full-time technical resource to manually update the master data. Someone who can work with the Business Experts and make the necessary adjustments to the data in the database.
Developing (in addition to the database/application/etc) a custom UI that is intuitive enough for the less-technical Business Experts to use for managing the master data themselves.
Neither of these were ideal from a cost-perspective. With MDS/DQS, a developer/contractor can come in, design an end-to-end Data Warehouse/BI solution including full integration with DQS/MDS (probably via SSIS packages) with relative ease. The Business-Experts can be trained to manage the master data using a UI they are already very familiar with (ex. Excel), and the developer/contractor can move on to the next project/client.
Also, if the business already has other data sources (via acquisitions or silo'd-yet-overlapping efforts or whatever), MDS can be used to manage all the master data in one centralized location.
It might not be the best MDS product available yet however it does come with SQL Server. Compared to most of the bespoke efforts for accommodating meta-data or master data in warehouse loads it's a pretty good option since most of the time is spent concentrating on the warehouse and the mastering of ancillary or other data isn't normally well accommodated for leaving questionable results. I prefer to use it than create some other flaky option that the customers will find it difficult to maintain. If you have budget however I would consider looking around for something more polished.
Like anything though give master data the respect it deserves. If it is going to be used then it's worth spending the time to model the entities, flow of data and usage correctly. The data stewards will need to savvy and will require training (it's not the most usable interface in the world - to say the least).
As we are a small consulting and development company we don't use MDS internally but we do implement it at customers with a focus on managing the Golden Record as the customers have a myriad of databases and applications all using the same data (customer, product …)
I agree with Lynn Langit's comment about installation and SilverLight dependency and the general comments about the UI. There are also a lot of smaller companies that don't run SQL Enterprise Edition but whom could benefit from MDS.
Those are the reasons why we are now developing a modern web application which we will host for our customers (probably on Azure).
If you're thinking about MDS I'd recommend to have a look at the API to replace (parts) of the UI.
Master Data Service is very useful for managing Master Data,
We have used Master Data Services 2012 and 2016, there are not too many features present in 2012 ,2016 is much better than 2012 with some new features , but I think still Microsoft needs to improve Master Data Services, they should include some flexibility in business rule's area.
I am looking for a easy to use and deploy sql type database i can ship with a desktop application.
This will be a small application user's can download from my website.
In the vb6 days, access was the common database for small desktop apps, what is my option these days?
Looking at SQL CE it seems to have a quite a few limitations such as count(distinct) etc
SQL express needs to be installed and running as a service (could i include the SQL express deployments in my deployment so the user doesn't even know its been installed? I assume size would then be an issue)
SQL 2005/2008 is not an option due to size and licensing restrictions.
I would like to use c#, wpf and entity framework.
What would seem to be the best options based on your knowledge and experience?
Thanks
SQLite (also see corresponding wrappers for the .NET Framework) might do the trick for you.
FirebirdSQL. More functions, plus UDFs made in C/C++ or even Delphi.
Which is a better choice on a development box if you primarily develop Asp.Net applications and SSRS reports. I have never had to use the Express editions, so I don't really know the pros or cons.
The cons I have listed for Standard+ editions are:
toll it takes on system resources
pain to attach database for projects
pain to detach unused databases
$$$
Pros:
You have everything you need
Management Studio features
Easy move to production
Are you talking about for your dev machine, or for production? If it's your dev machine I would just pony up the ~$50USD for the developer sku, the only caveat is to make sure you don't make use of enterprise features unless you will have enterprise in prod.
I don't have experience with the 2008 versions as yet, but I've used both the 2005 and 2000 equivalent (MSDE) on live production projects. The codebase for both of these is essentially the same as the full blown product but with restrictions on ussage and the absence of some tools - the later of which can be generally worked around with 3rd party replacements.
If the number of concurrent users is low, and the the database is unlikely to grow that large, then generally the express versions are fine. It's a little more hassle to manage than having the full edition to hand, but the cost saving is significant.
Low and that large are of course elastic, but for example we have a real estate application that runs in several offices with half a dozen users and a couple of tables with a million rows and performance and management is perfectly fine.
SQL Server Developer Edition.
The only problem you have to watch out for is that it has features not available (it basically has the Enterprise Edition features) in the Standard Edition (for example, indexed views).
So, for instance, dev edition will work much better than express on your quad-proc dev box.
http://www.microsoft.com/sqlserver/2008/en/us/editions-compare.aspx
Usually there is no "Best" choice, however in this case there is: SQL Server Developer Edition. Reason: It gives you everything in every other edition (except the licensing) for all of $65-$90. Seriously, any SQL developer would be crazy not to get it, it's one of the best deals in the history of software.
Other stuff that you mentioned:
System Load: this depends much more of how you use it than what edition it is. I have both 2005 & 2008 instances running on my 3 year-old 2GB laptop with no ill effects.
pain to attach database for projects: painless with developer edition.
pain to detach unused databases: same
"You have everything you need": now you have everything that you will EVER need (for 2008).
Management Studio features: Yep
Easy move to production: Yep
Honestly, at this price, employers should be giving this to all of their developers.
On the rare occasions where I am in the same situation (usually on my personal web hosting), I opt for sql express + various free or cheap third party tools to substitute for SSMS and EM.
The development editions have all the features of the enterprise editions (with some quirky exceptions, consult BOL), so it's not like the dev edition will give you fewer things to play with. You just won't be able to let any of your customers connect to your SQL developer edition, you'll have to deploy your SSRS reports to a Standard Edition production server somewhere.
If you are using SQL at work and your employer doesn't have a license for SQL Standard at all, then that sound like a licensing problem.
In short, I think the choice of edition starts with a choice of license, which is an economic and legal question, not really a feature set question. (i.e. will your planned uses be legit with your chosen license? with SQL Express and Dev edition you can't wrong-- the sql express has you covered for production use, the dev edition has you covered for being able to use the features you want, like SSMS)
Express isn't really designed for actual products - it is more to let developers familiarize themselves with the system and see if they like it, or for sample apps.
Express is free though, but if you need a free solution you might be better off with MySql.
There are a couple of questions on Stackoverflow asking whether x (Ruby / Drupal) technology is 'enterprise ready'.
I would like to ask how is 'enterprise ready' defined.
Has anyone created their own checklist?
Does anyone have a benchmark that they test against?
"Enterprise Ready" for the most part means can we run it reliably and effectively within a large organisation.
There are several factors involved:
Is it reliable?
Can our current staff support it, or do we need specialists?
Can it fit in with our established security model?
Can deployments be done with our automated tools?
How easy is it to administer? Can the business users do it or do we need a specialist?
If it uses a database, is it our standard DB, or do we need to train up more specialists?
Depending on how important the system is to the business the following question might also apply:
Can it be made highly available?
Can it be load balanced?
Is it secure enough?
Open Source projects often do not pay enough attention to the difficulties of deploying and running software within a large organisation. e.g. Most OS projects default to MySql as the database, which is a good and sensible choice for most small projects, however, if your Enterprise has an ORACLE site license and a team of highly skilled ORACLE DBAs in place the MySql option looks distinctly unattractive.
To be short:
"Enterprise ready" means: If it crashes, the enterprises using it will possibly sue you.
Most of the time the "test", if it may really be called as such, is that some enterprise (=large business), has deployed a successful and stable product using it. So its more like saying its proven its worth on the battlefield, or something like that. In other words the framework has been used successfully, or not in the real world, you can't just follow some checklist and load tests and say its enterprise ready.
Like Robert Gould says in his answer, it's "Enterprise-ready" when it's been proven by some other huge project. I'd put it this way: if somebody out there has made millions of dollars with it and gotten written up by venture capitalist magazines as the year's (some year, not necessarily this one) hottest new thing, then it's Enterprise-ready. :)
Another way to look at the question is that a tech is Enterprise-ready when a non-tech boss or business owner won't worry about whether or not they've chosen a good platform to run their business on. In this sense Enterprise-ready is a measure of brand recognition rather than technological maturity.
Having built a couple "Enterprise" applications...
Enterprise outside of development means, that if it breaks, someone can fix it. I've worked with employers/contractors that stick with quite possibly the worst managing hosting providers, data vendors, or such because they will fix problems when they crop up, even if they crop up a lot it, and have someone to call when they break.
So to restate it another way, Enterprise software is Enterprisey because it has support options available. A simple example: jQuery isn't enterprisey while ExtJS is, because ExtJS has a corporate support structure to it. (Yes I know these two frameworks is like comparing a toolset to a factory manufactured home kit ).
As my day job is all about enterprise architecture, I believe that the word enterprise isn't nowadays about size nor scale but refers more to how a software product is sold.
For example, Ruby on Rails isn't enterprise because there is no vendor that will come into your shop and do Powerpoint presentations repeatedly for the developer community. Ruby on Rails doesn't have a sales executive that takes me out to the golf course or my favorite restaurant for lunch. Ruby on Rails also isn't deeply covered by industry analyst firms such as Gartner.
Ruby on Rails will never be considered "enterprise" until these things occur...
From my experience, "Enterprise ready" label is an indicator of the fear of managers to adopt an open-source technology, possibly balanced with a desire not to stay follower in that technology.
This may objectively argued with considerations such as support from a third party company or integration in existing development tools.
I suppose an application could be considered "enterprise ready" when it is stable enough that a large company would use it. It would also imply some level of support, so when it does inevitable break.
Wether or not something is "enterprise ready" is entirely subjective, and undefined, and rather "buzz word'y".. Basically, you can't have a test_isEnterpriseReady() - just make your application as reliable and efficient as it can be..