Ask Slashdot: Linux Database GUI Application Development?

New submitter msubieta writes I have been developing some applications to use in small businesses using Windows and SQL Server. I would like to move on and start doing the same thing in Linux. I have looked at several Frameworks/Databases/Development environments and I really don't know what is the best/simplest/fastest to learn approach. I use VS and C# mostly, although I could easily go back to C++. I found Qt and GTK+ are the most common frameworks, but they seem to lack controls that deal with datasets and stuff (sorry, spoiled by the .net form controls), but I also know that I could use Mono in order to make the jump. I would have no problem on moving to MySQL, as I have done quite a lot of work on that side, and I would like to stick with the traditional client server application, as I find it easier to maintain, and a whole lot more robust when it comes to user interaction (web apps for POS applications don't seem to be the right way to go in my view). Any suggestions/comments/recommendations?

Comments

MySQL GUI tools list

[shmorhay]

Here is a Database Journal article from 2010 listing some useful MySQL GUI development tools that may provide some leads -- http://www.databasejournal.com...

Biased, but...

[tyroneking]

I'm biased towards Python - and the following suggestions have nice UIs but they are web-based - so please forgive me in advance ;)

After years working in Siebel (UI dev tools, transparent database interface, etc) moved over to Linux dev and was stuck for a while - finally settled on Flask (http://flask.pocoo.org/) a Python micro-framework, which is light (i.e. not as incomprehensible as Django ;) but comes with a lot of functionality if you need it. Jump in. Here's a good guide that mixes in Bootstrap to make a very appealing UI - http://flaskbook.com/

Alternatively, go all ERP with lots of built in business functionality and nice UI features and try ERP Next (https://erpnext.com/) - which I'm looking at right now. It has some poor documentation, but the dev guide for the underlying framework (Frappe) is pretty clear (e.g. https://frappe.io/developers/g...) and looks less scary.

I'd consider Go and PostgreSQL

[MillerHighLife21]

Go is still young so if you're looking from a "language saturation" standpoint, it's not where you want it to be yet but it's gaining traction fast. It will be familiar from a typing standpoint and as a language it provides excellent concurrency, which in certain types of applications becomes a really big help. By learning Go you'd be providing yourself with a language that helps solve a complicated use case rather than just another language that does exactly the same things as other server side languages. It's compile time is almost instantaneous which is similar to a scripting language. Runs well on both Windows and non-Windows environments too, which will make it easier to use it along side your existing .NET stuff if needed.

PostgreSQL as a database is pretty much amazing. Everything you like from SQL Server is there without a lot of the stuff that you don't. Here's a writeup that I did a few months back breaking down what's great about PostgreSQL in as concise of a post as I could. http://www.brightball.com/post...

Since this is a specific "what should I learn based on my current background" type question, that's my recommendation for YOU based on the post.

Re:I'd consider Go and PostgreSQL

[greg1104]

That's a nice outline of Postgres features; small and very pedantic correction for you. CREATE INDEX CONCURRENTLY in PostgreSQL isn't really asynchronous, since the client running it is stuck there waiting for it. And it does still need a full table lock to complete. It just only needs that for a brief moment in most cases, to install the index when it's built. But that's not guaranteed. I added a caveat to the docs a version or two ago that warns about the bad case; see building indexes concurrently, in particular the bit starting with "Any transaction active when the second table scan starts..." It's really rare that happens, but if you have long-running transactions eventually you'll run into it painfully.

I would restate the situation as "You can even create indexes with minimal locking of large tables when a new index is added". The code can't quite avoid locks altogether and remain transaction safe.

GUI Datasets

[StormReaver]

Having programmed in GTK+, Qt, Java, and C#: I find C# to be the most painful for database interactivity. Its data bound controls (to me) are infuriatingly convoluted, complex, inefficient, and inflexible.

I find it far, far easier to use a tool that generates database models, create readers and writers based on those models to abstract them away from the application, and then use those readers/writers in the mainline application. The payoff is immense.

The closest fit for you is Java (since C# started life as Microsoft's attempt to make a Windows-specific version of Java). The two best IDE choices then become Netbeans and IntelliJ (do yourself a favor, and skip Eclipse).

Re:GUI Datasets

[Richard_at_work]

You might want to take a longer look at C# because there is no reason you can't just use Entity Framework to do exactly what you find it easier to do - create the model, creates readers and writers, abstract the database stuff away and just get to use plain C# objects, lists, collections and other things instead of cumbersome DataTables or Datasets etc.

Look at Java/Postgresql

[Anonymous Coward]

I've been exploring the same route. There are a lot of options but none as mature (from the developer's perspective) as what you are used to. After a lot of search and trial and error,

I've settled on PostgreSQL for database since it is mature, fast, easy to manage, and generally solid. It's really comparable to what you are used to in MS SQL Server.

For languages, I've settled on Java, which I swore never to do. It's not as robust as C# since there was a leadership vacuum for too long at Sun's demise and Oracle's stumbling. It's catching up, though. Just avoid using reflection. It's a dog in Java. Also, don't assume that generics are the same thing in C# as in Java. C# allows a lot of runtime generic goodness where Java allows it for coding but it compiles down differently, stripping out a lot of what you would expect. Other than that it's very close to C# in use and a stable language.

For the IDE, I recommend going with Eclipse. It can be a pain when you are user to VS but it's the closest I've found for maturity and features. Also, being written in Java, the "eat you own dog food" test has proven useful. It's good for Java, not so much for other languages. Not that you can't do a lot with other languages in Eclipse... Lord known I've tried. Use the Kepler or later build. Older versions had some issues, particularly with source control integration. I'm on Luna and it works well on Linux AND Windows.

Another side note: This setup works equally well on Linux, OS-X, and Windows. I've been looking for a solid cross-platform setup for years. Avoiding Java was a waste of time. I miss the C#/VS/MS stack for it's solid performance on Windows but, as you know, it was a no show for every other OS out there. This stack works on everything. It's a pain to switch but if you've been in the business for long you'll be productive again in a week or two.

Good luck.

Re:Not a joke, Microsoft is open sourcing good bit

[Anonymous Coward]

We're looking at 2 years minimum for .Net Core to be solid and complete for Linux. I've been following this closely. Tools are totally missing as well, which you mentioned. I don't see something like Visual Studio even being ported unless MS abandons the "Windows is dominant" position. If they do, I don't expect a solid showing for VS until 2020 at the earliest. For now you are stuck with Mono, which isn't bad, it's just anemic compared to VS.

Qt + C++

[ClayDowling]

I'll recommend Qt and C++ as a workable combo. Learn how to use their Model/View architecture and there's a whole lot of fun stuff that opens up for you. Instead of looking for database components, think in terms of writing a data model that happens to get its data from an SQL backend.

I'll also second the recomendation of others to look at PostgreSQL for your backend. When it comes time to deploy your application, PostgreSQL is a lot easier to package and install than SQL Server. The features aren't identical, but they're close enough for all but some very specialized cases. In a lot of those cases, there are tools that accomplish the same goals via a different mechanism.

Re:Hakija

[ClickOnThis]

Name 3.

You want 3? Here are ten. And there are more.