Induction: A Polyglot Database Client For Mac OS X
inductionapp.com
inductionapp.com
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)
http://code.google.com/p/sequel-pro/issues/detail?id=362&...
Developer input from mid-2011 is towards the bottom, but in short the gist is "that would be great, contributions welcome".
If only it were as easy as `gem install pg`.
I would totally throw $20 at a kickstarter to pay someone. That's what, optimistically? Two weeks of work? How quickly could we scrounge up $10k?
Shit. More like $100, now that I think about it.
It is with MacRuby, but that's a whole different set of problems :)
Apple highly encourages using ARC over GC for new development.
Their wording there is suspect though. Interesting - thanks for the link!
I guess you meant latency, where reference counting generally has better latency than incremental garbage collection.
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.
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.
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).
4) It's free.
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.
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 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.
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].
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.
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)
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.
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.
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?
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.
[1]: https://www.surveymonkey.com/sr.aspx?sm=2RYrV_2bFw2aZ2RfedWH...
Installed base is irrelevant if you include the libraries or statically link. You'll bloat your download a few MB, but it's manageable.
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.
Both GTK and QT are available on OS X, Windows, and Linux. Cocoa is available on OS X only.
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.
If somebody was going to work on something like that, I would love to help. Mail in the profile.
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.
What am I missing?
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.
Edit: I could have answered this question for myself by reading... Skimmed the line that explains that on the site and just caught it now. Oops ;)
I'm yearning for the MongoDB support myself.
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).
For my use case, that would be the holy grail.
(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)
Binaries are up at https://github.com/Induction/Induction/downloads
Let me know what build errors you're getting. I would do well to document the requirements (Postgres, Redis)...
Induction is my first real project with ARC, so I'm figuring this out as I go along.
(I don't think that it supports noSQL.)
I like it, looks much nicer than any of the solutions I'm aware of currently.
- Navicat - PGAdmin III - SeqlPro
Looks like I will add this as a fourth. Big win on the visualization feature!