Can't someone just add database drivers to Sequel Pro? It's far and away the best Database GUI I've ever used and its reliance on MySQL is actually keeping me from moving to PostgreSQL full time.
God I would love this. This really is the best GUI DB client. I use Navicat for PGSQL but its not free and its quite clunky (though to be fair, very powerful). In any case, SQLite and PGSQL support are supposedly in their roadmap.
It's open source, so anyone can add their own db drivers to it. The problem, as with other open source projects, is that the task is not trivial. (I tried to patch Sequel Pro last year) Which is also why I don't buy the oft-quoted benefit of OSS being that you have access to the source to fix/add things. BS.
Oh yeah, last time I checked, Sequel Pro doesn't build in XCode 4.
> benefit of OSS being that you have access
> to the source to fix/add things
The place where this is the most beneficial is when considering businesses looking to invest in a technology. If you invest in a company/software product that goes under, then you could be saddled with a piece of tech that you can't fix bugs for, etc. If it's open source you at least have the chance to do so, even if the community around it collapses and there is no new development.
The idea that access to the source is some sort of cure-all is a fallacy, but it may also just be a straw man. I don't know that anyone says that all open source projects are going to be manageable just because the source is available, but they are by definition more manageable than a project with no source available.
Well yeah. One is compiler-assisted reference counting and the other is garbage collection. Reference counting is nearly always faster than garbage collecting, and Apple has generally been a bit obsessed on speed, for however much that has gained them or lost them.
Their wording there is suspect though. Interesting - thanks for the link!
I've never used Sequel Pro, but I've used plenty of other RDBMS GUIs. What's so special about Sequel Pro? It certainly doesn't look like anything to write home about (compared to say the MS SQL tools).
1) Every GUI function results in a SQL log entry so you can learn/improve your SQL if you're not a guru.
2) You can give this to an analyst (whose db user is restricted appropriately) and have them be productive in adding and updating data.
3) Any view can be exported to CSV, so the analyst can use what they know (ie, Excel) to do things you might not care about but are important (ie, pivot tables, etc).
Thanks for the list. Those are nice features. The SQL Server tools can do all that (except the free part, but the cost of the client is kind of included in the SQL Server license cost). Still, sounds like a nice app.
I can't speak for the MS SQL tools. I used one of them once? and it was extremely lame but I can't comment.
Compared to every other RDBMS GUI I've used:
It crashes very infrequently. It doesn't randomly slow down whenever I click on something. The settings page is relatively straightforward. There aren't fifteen different windows with different functions. The UI makes sense and is also very straightforward.
re: MS SQL Server tools and lame - really? The SQL 2000 tools were pretty basic, but since about 2005 they've been pretty good. I'd be interested to hear what you found lame. I guess maybe you were using something else from MS' cornucopia of GUI database tools (a plethora of wizards inside visual studio, access etc).
So, I was rescuing an MS Access application that imperfectly synched from a MySQL instance powering the Rails app from which it got data, that had been exported to MS SQL that was running (surprisingly well) inside a Windows XP VM I was accessing via Remote Desktop Connection.
So: I have no idea. I totally forget. It was some really-complicated-looking MS tool that allowed me to look at the table row by row and run some queries :). The guy I was working for set it up; my excuse is I stopped using windows back in 2004.
There's nothing particularly special about it, except for the fact that it just works significantly better than any other RDBMS GUI program I've ever used. The UI is great, it's fast, it's simple to use, and I've never found a feature I needed that it doesn't already have.
How easy it is to install and maintain. How performant it is. How good are the tools associated with it.
I've yet to run into a situation where MySQL was holding me back. Since the only thing postgres has got going for it, from my standpoint, is that my friends prefer it and it is cooler… I think that until I have a better reason I will stick to the one with the better toolset.
Right now, Sequel Pro is that tool. I use it almost every single day.
This idea is friggin awesome and definitely something I'd pay for. My apps are pretty evenly divided at this point between MySQL, Postgres, and MongoDB, and I don't see that trend going away any time soon (we always pick the db that makes the most sense for each particular project). Having them all available in the same app would be amazing.
With that in mind, just to warn everyone, this is very alpha-level software. It only supports postgres and redis right now. If you put the wrong credentials in, there's no feedback, it just seems like nothing happened. Also, trying to resize the window turned everything white for me and the app had to be rebooted.
If you decide to use it (and please do, because I want this to work), be sure to have your Mac's system log opened in console, so you can see what's going on.
UPDATE: Looks like someone has already submitted a pull request for the "no feedback on wrong credentials" bug I mentioned [1], and I created a ticket for the resize issue [2].
"for Mac OS X" breaks my heart, because this is exactly the kind of open-source DB client I want on Linux.
At least I can use this when I'm on my Air, but I recently went looking for a multi-DB client app like this for Linux, and this looks like what I was wishing I would find.
Written to what API? Gnome, X, Qt? You'll be addressing a slice of a fraction of potential users. It'd be great if it weren't the case, but the diversity that makes linux interesting to hackers also makes it really tough to roll out GUI apps like this and have it 'just work'. I get the sense that's a good part of the appeal of OS X for the developer community lately - mostly Linux-ish when you need it, but a unified GUI experience for the pretty tools (e.g. TextMate, Base, and so on)
That's just patently untrue: either GTk or Qt would work perfectly. I don't see why the desktop environment would matter--the program doesn't have to (and probably shouldn't) care whether I'm on Gnome or KDE or Unity.
Moreover, all the popular environments support both GTk and Qt fairly well, and both are cross-platform, so you would actually be supporting more users than with a Mac OS-only program.
Really, fragmentation like this is not nearly the issue people make it out to be. Basically, everybody can use everybody else's programs on Linux, with the exception of very odd or customized systems. And the sort of people who have very odd and customized systems can fix problems themselves.
EDIT: Also, you could use wxWidgets. That would give you a native look on all the platforms you support.
I would also like to clarify that I understand an OS X user wanting to write an OS X-only program. The real issue is dissuading others from supporting Linux because of non-existent fragmentation issues. They simply do not affect people using GTk or Qt, in practice.
> Moreover, all the popular environments support both GTk and Qt fairly well, and both are cross-platform, so you would actually be supporting more users than with a Mac OS-only program.
By that logic Windows should be first since it has the most users. Also, are you sure that the installed base of Gtk+ or Qt (or both) is greater than the installed base of OS X?
Well yes, because unless I'm much mistaken, Qt and GTk are both supported by OS X so they are both supersets. (This is obviously ignoring Windows, which is also supported by Qt and GTk but is probably difficult for other reasons.)
There are also cross-platfrom native options like wxWidgets. These also work both on Linux and other systems.
Finally, the last StackOverflow survey[1], which I think is pretty representative of the sort of people who would use a program like this, had both Linux and OS X at about the same level (~20% each). So Linux is certainly not negligible.
I wasn't taking anyone to task for not building it. I was saying what I, as a user, wish I had available to me for my primary dev environment.
I don't care what toolkit it gets built in. I typically use Gtk-based environments and stick with Gtk apps but have no problem using a Qt or other toolkit app when it meets a need.
For very, very low values of "available", especially when it comes to GTK. If you're going to release a GTK application for OSX, you can just step the release part entirely.
Nobody targets X as an API anymore and haven't since Tk, this is a canard.
In general, given the demographics of desktop Linux, it's safe to assume everyone has GTK and Qt working, so pick whatever suits you and go for it. (Spotify is Qt IIRC)
Honestly it wasn't meant as a canard — this was basically my thought process when I was thinking through an app idea. I'm surely uninformed and some of that is a function of my own laziness, but it's also a reflection of how much diversity there is. I feel like it's akin to Kissinger's rhetorical (at the time) question "Who do I call if I want to call Europe?"
You just pick whoever people listen to at the time you make the call. In this case, GTK and Qt have been calling the shots and all Linux installs worth targeting are going to support them or support installing the dependencies necessary (which you can specify in your package, as spotify does).
Flailing about and perpetuating this myth that Linux is impossible to target just makes things worse.
Back in the day you could whip together an app like this using Borland's dev tools in literally a matter of minutes, and it worked with any data source configured on your system.
And I think there's a YouTube video that has Steve Jobs demoing that same sort of data access using only Interface Builder on NeXTSTEP.
ODBC is fairly complex (both to work against and to implement providers for) and is very much tied to relational databases.
It's also unevenly implemented: On Windows there's native Microsoft-provided ODBC (but in terms of focus it has been superceded by ADO, which superceded OLE DB, which was supposed to be the replacement for ODBC — it's not like Microsoft ever settles on a single technology), and on Unix there's UnixODBC. I don't know about the driver quality; I suspect Windows ODBC drivers are quite good, whereas JDBC has been favoured by the server/enterprise world for a while, and I would not be surprised if UnixODBC drivers were a bit behind the times.
As for the Borland dev tools, they also used their own proprietary data source tech: The BDE (Borland Database Engine), which had an ODBC bridge built in. I remember being quite fed up with the BDE at the time, and eventually started using a set of native ODBC components that someone developed.
Cocoa does have a sort of rich data framework that you refer to: Core Data. Unfortunately it's quite complex, and not really designed to be a common interface to databases, but rather a sort of data abstraction layer where you work with objects and never see any SQL.
Does anyone have an actual build of this? I just uninstalled XCode this morning and replaced it with Apple's new CLI dev tools, otherwise I'd try building it myself.
I didn't notice the note at first either. They should probably revise the whole sentence to make it clearer that it doesn't yet support those "out-of-the-box" instead of a note afterwards.
Wonder if I'll be able to get this working with Oracle. Unfortunately (believe me, I've complained and hope to change it in the future) I have to use Oracle at work. Would love to use this.
Oracle support would be very awesome (and hopefully very possible). I designed the protocols to be extremely simple; check the Postgres one for an example (~500 LOC)
Looks interesting, but there are no binaries and the XCode project didn't compile right away.
(I guess, being a software developer, I should go and try to figure out what's breaking the building process. On the other hand, I've never used XCode and don't know enough about OS X library management to figure out broken deps)
I wonder if this could be used to hook up something Excel-ish to a DB backend.
I use Excel frequently to model and ask "what-if" questions but I often wish I could store/retrieve information dynamically from a DB. (The ODBC connectors that Excel has leave much to be desired).
Somewhat off topic, but I remembered the author of this Excel add in's "Ask HN" when it first came out ( http://news.ycombinator.com/item?id=794317 ). 2 or 3 years later, it looks like he's expanded and now has 2 software products and a SAAS ( http://www.OakFocus.net/ ), so very inspiring.
It should be noted somewhere that this project currently appears to only work on OS X Lion due to usage of a few Lion-specific classes, namely NSOrderedSet.
Can't someone just add database drivers to Sequel Pro? It's far and away the best Database GUI I've ever used and its reliance on MySQL is actually keeping me from moving to PostgreSQL full time.
(i.e. http://www.sequelpro.com/ and http://www.sequelpro.com/docs/Source_Code - a little crazy they're still on SVN but oh well)