We Keep Coding

iOS remote MySQL database, technology recommendation

There is web application, journalism related, that uses MySQL databases and presents a web based interface to users.
I want to build a iOS app that does a mobile interface as well. The UI is pretty easy and I have experience with that.
The problem is with the database, which I have no experience with.
I will be learning about databases and probably take the Coursera course on it. I am not asking you to teach me that. I just wanna know which technologies I should invest my time in over the next couple months.
My understanding so far is that the app should not talk to the database directly,
but rather there should be some one on the server talking to the database on behalf of the App.
This is the question and the part I want to understand clearly, so correct me if I am wrong.
I will have to write some sort of a unix program that runs on the server and talks to the db and then communicates back to app? how? using a web view? Using unix sockets to talk to the app? ssh? Which one is cool with Apple?
My preference for writing something like that on the server would be: python(have experience), java(have experience), and maybe ruby(no experience). I'd prefer to avoid scripting languages.
Are they ok? Which one is best suited? Also is this middle dude going to have to be on the same server that has the database or can be another machine on the internet(i'd prefer this, so i can put it on my own VPS and not have to screw up with the server machine)

This is similar to another question from tonight, but you're coming at it from a different angle.
In general terms, an iOS application that needs to be able to run in offline mode will need to have its own database. This means creating Core Data models to store all of the data required by the application. Internally this is stored in a SQLite database.
If you want to make an application that's online-only, it's somewhat easier since you won't need to worry about the Core Data part and can instead focus on building your service API. If you're familiar with Python then your best bet is Django to provide that layer. You'll need to implement a number of endpoints that can receive requests, translate that into the appropriate database calls, then render the result in a machine readable format.
Scripting languages are what power most back-ends even for massive scale systems. In most cases the database will be the bottleneck and not the language used to interface with it. Even Twitter stuck with Ruby until they hit tens of millions of active users, so unless you're at that level, don't worry about it.
For most applications, using HTTP as your transport mechanism and JSON as your encoding method is the way to go. It's very simple to construct, easy to consume, and fairly easy to read. There are probably a number of ways you might go about reading and writing this, but that's another question.
For small-scale applications where the number of users is measured in the hundreds then you can host the application and database on the same server. Even a modest VPS with 512MB of memory might do the job, though for heavier loads you might want to invest in a 1GB instance. It really depends on how often people are accessing your application and what the peak loads are like.

Need to replace complex MS Access by JAVA / Oracle or MySQL

Hi DB experts out there,
what do you SQL experts recommend to substitute a couple of MS Access databases by s.th. more modern like JAVA / Oracle or JAVA / mySQL?
The databases are small, not more than a few thousand records each. so there is no need for performance speed on the DB side.
But all of the MS Access stuff has complex forms with colors (for information purposes), details, nested sub-forms and a lot of nested queries.
Since MS Access is hard to debug and misses modern development tools as those in Eclipse I think about a redesign of the old stuff.
Said with other words, what is the best way to substitute especially forms?
Is Java Swing a good library to rebuild all the form stuff?
Or should I stay with the old stuff?

It depends how much time you want to spend on your new-design and who is using MS Access.
As you said, your MS Access db is very complex. If you want to replace this with mysql/oracle, it may take you long time to redesign the presentation layer (as you said, colors, details and so on.)
If you have time, you can design as totally new MVC framework project instead of old MS Access by using all new technologies. And you can learn a lot.

Not really a db question, the forms side of it is access as an application language not a database, whatever you choose you are looking at a good deal of work in Java if that's your application language choice.

This is a serious question: can it look like crap? Whatever tool you use, you'll probably want some kind of form-generation support (just to move things along). Form generation tools are all bad. It's a rule. But, they're bad in different ways. Also, having said that, I've never used one for Swing, as my desktop app forms were easy enough to build by hand. JFormDesigner looks feature rich and has some good-looking forms to boot (but because of the rule, we know you'll hate something about it).
If you want to stay with the old stuff, I recall that you used to be able to use access on the front end and connect to a different database server (SQL server). Depending on what year the access system is, you may have to replace immediate if (IIF) statements and do some other translation, but it would give you a database that makes troubleshooting queries a little better.

I guess only you can decide "why" you want to do this. If it not broke, then why fix it?
You can use source code control with Access if you want. I cannot say the debugging tools in Access are great, but then most Access applications tend to not have tons of code anyway. (much of the forms etc. work without code). And the report writer has received some upgrades that makes it even better – still one of the best around.
And Access 2010 has web like controls and effects now, so your screens can look like this:
Even the above round buttons and shadow effects where built using ONLY the tools inside of Access. So the new design options are quite extensive.
Same goes for the new navigation system you see on the left side. (no thrird party tools were used for above. So here is a SMALL sample screen shot of some new design options:
Also +1 for those here that pointed out that moving the data to MySql or some such is NOT the same as what you going to develop the application with.
Access is more of the development tool and part then that of the just some tables. The tables can be sent off to darn near any system like SQL server, MySql etc.
The problem and question and challenge is that of building the application part with the code and logic.
Speaking of SQL server, Access 2010 has baked in support for the cloud edition of SQL server. So Access works with SQL Azure. So if you looking for a cloud play, this setup works with Access.
Access also allows your tables to moved up to the new office 365. This is a great low cost way to get into cloud computing. And the office 365 setup allows Access to go "off line" mode. This means your laptops can go out, run the Access desktop application, and when they find some wi-fi or get back to the office, they sync their data. This is a true automatic "replication" model but works without any coding on the part of the Access developer.
And if you have SharePoint, then your tables and "off line" mode works with that.
Last but not least, Access now supports web publishing of your database. This works with office 365 or SharePoint.
This web publishing is true cloud computing with unlimited number of users. The only real limits are the capacity of Microsoft's computer farm (and it is really big one!).
Access forms when web published are converted into "zammel" .net forms (XAML). The Access code you write in the forms are converted to JavaScript and in fact this code runs "browser" side. (so you are building true multi-tier applications). Your table procedures you write inside of Access go up and run server side – even on office 365 (Not even .net developers can have code run so easy on office 365 servers!)
For those who not seen the web ability, in the following video, I switch to running the Access application 100% in a web browser at the half way point:
http://www.youtube.com/watch?v=AU4mH0jPntI
Such web applications built in Access don’t' require ActiveX or Silverlight, and as such they run fine on my iPad.
So, I am not really sure if one needs to get "caught" up on all of the new buzz words.
But if you looking to using office 365 and publish web forms, then Access does this now.
And if you looking to use the latest and greatest new edition of SQL Azure that runs up in the cloud, then again Access can be used.
And if you looking to use Access with SharePoint which is really popular, then again Access can be used.
And if you want "cool" shaded buttons with cool "hover" effects, then the new Access designer has these types of choices:
So there is tons of neat-o buzzy gee wiz bang things you can do with Access. Heck you can even build custom ribbons in Access now!
However, if you have a few basic forms that work just fine now? Why not just stick with what works?
I vote for KISS.
No real need to get caught up in the latest fads, but if such is your cup of tea, Access does have lots of that "new stuff" to play with these days.

Complex data-driven web application in Java - Decision on technologies

Dear Stack Overflow Community,
I am a Java programmer in front of a task of building a complex, data-driven, web application (SaaS) and I'm searching for technologies to use. I have already made some decisions and I believe I'm proficient enough to build the appliaction using just the technologies I have decided for (I'm definitely not saying it would be perfect, just that it would be working). However, I'd like to make my task easier and that's why I need your help.
Brief description of the project
Back-end
The application will be heavily data-driven, meaning that everything will be stored in a self-descripting database. This means the database itself will be entirely described with metadata and the application will not know what data it reads and writes. There won't probably be any regular entities (in terms of JPA #Entity) because the application won't know the structure of the data; it will obtain it from the metadata. Only the metadata will have a pre-determined structure. To put it simply, the metadata is the alpha-omega of the application because it will tell the application WHEN and WHAT to display and HOW to display it.
The application will probably utilize stored procedures to perform some low-level tasks on the data, such as automatical auditing, logging and translating to user's language, thus most likely eliminating any possibility to use ORM frameworks because there won't be just simple CRUD operations. Therefore, JDBC seems like my only option (doesn't it?).
Front-end
The UI will be "dumb" in terms that it will not know what data it is displaying (to some extent, of course). It will just know how to display it based on the metadata which it will obtain from the database. All UI controls (like menu items, buttons, etc) will be created based on current application's state and the UI will NOT know what the controls do. This means that clicking a menu item or a button will just send an identifier of associated action to the back-end and the server will decide what to do.
My goals
My main goal is to have the application as lightweight as possible with as least dependencies as possible. Because the application will be very complex, I'd like to avoid any heavy framework(s) because there is a very high probability that I'd need to customize a lot of its functionality.
What I have already decided for
Please object to the following decisions only if you think they're absolutely non-viable for my application, as I have already implemented some core functionality using these technologies:
Servlets on Tomcat, Guice DI, AOP (AspectJ)
I believe all of these technologies are lightweight enough and I don't need to learn J2EE.
GWT with GIN-jection on the front-end
Seems like the best option for me because I'm very familiar with Java and Swing and don't want to write any Javascript, PHP or learn a new language. GIN is a little brother of Guice and I will be using the same syntax and principles on both the client and server.
MSSQL RDBMS
This is actually a requirement from company management as I'd much rather like to go with an open-source solution. Too bad for me..
Maven 2
I think no-one can object to this :)
What I need help with
DB communication
I think that ORM is ruled out (is it?) so I need to use JDBC. Do you think Spring JDBC is lightweight and flexible enough for my use? I would often need to "blindly" read data from database, mapping it to some generic entity (because I won't assume any pre-determined structure), and then send the data using some generic DTO to the client along with the metadata telling it what data it is and how to display it. Or do you know any alternatives? Or should I do this myself?
Client/Server communication
GWT and its GWT-RPC mechanism seems not very suited for sending the generic data I need. Although I'm convinced that it's doable using GWT-RPC, are there any alternatives? But I definitely want to use GWT.
Security
Do you know any security libraries / frameworks that would help me? I'm aware of the existence of Spring-security; do you think it's flexible enough for my use or I'd be better off implementing that myself? Also, is Spring's IoC an integral part of the Spring framework, or would I be able to continue to use Guice?
Anything else that you think might be useful?
I really appreciate any advice and suggestions because I wouldn't dare to try to make such decisions myself. Please ask me if you need more information.
Thank you in advance!
eQui

I think you are over-engineering the solution. Take a look at
http://thedailywtf.com/Articles/Programming-Sucks!-Or-At-Least,-It-Ought-To-.aspx
If everything is driven by the DB, you are going to have immense difficulty making things happen in the UI, and you aren't going to be able to use many of the tools that make UI development easier.
I also suggest you take a look at Spring Roo, if your application is mainly just updating data in a database.

UI framework and implications for client/server communication
You say that any UI action will triger the backend (and potentially the DB). This mean that UI interraction will be somewhat slow anyway, and more than that will require a round trip to the server.
GWT is especially suited to avoid as much as possible round trips to the server and do all UI work on client side. In this model, only information that will transit from client to server is real data, and not UI metadata. GWT will do the job, but you'll be using a somewhat low level tool, needed for advenced optimisation you'll be unable to perform anyway...
Framework like ZK or Vaadin seems more suited to what you want to do. The client side has nice widgets with a rich UI, but you manipulate the UI from the server side. The framework manage client/server communication for you (no need of REST, RPC or javascript). The main limitation of theses framework is scalability, with all theses chatty round trip. But because your requirement impose that chatty behaviour anyway, you could really benefit from the abstraction they provide, are they are at not cost in your case.
I have tried both GWT and Zk to do some proof of concept for my company. We ended choosing GWT, because of it's hability to be embedded nicelly into any existing UI and to fine tune what you do... In particular avoid as much as possible rountrip to server. But ZK is really easier and faster in term of developmeent hours.
The side effect is that would totally solve your client/server communication concern, leting the framework performing it in an optimized way (Zk is able to intelligently regroup several UI event before sending them to server).
DB and ORM
For DB design, i tend to think that using fine granularity things in DB will make it very very slow. If each widget is one or several rows in the database you'll have to perform many lookup to perform the simpliest thing.
Problem is if your UI is just a little complex with a few dozen of elements (a few button, checkboxes, labels and widgets), compositing a screen will require lot of requests to the DB. Rendering just one page might be very slow and scalability would be very very bad.
I know this because i worked on somewhat generic bug tracking system with similar (but simpler) requirements than yours and we had exactly this problem.
So i would try to describe UI in some templating or XML format. Maybe you'll not show this data to the user, providing it with a nice abstraction, but instead of performning many queries for just one screen, you'll save the whole screen as one blob.
A really dumb and basic implementation of this would be to store HTML/CSS/PNG file in your DB and load it as needed, with user being responsible for making theses HTML file by hand. Of course this would be terrible for the user. That's why you need a nice and fancy editor UI editor that would work on an intermediary format of your own. Another dumb implementation would be some sort of wiki templating. This is not what you need, you need more. But you have the idea, I would seek in that direction...
For the maintenance and debugging too, this would be far easier to the whole UI description to a few file, to understand what is really implemented than to read lot of tabuled data in your prefered SQL editor. Users would have they export/import format to easily version, backup or experiment.
Security
I would say by hand... Because you have a generic UI generated by user it seem likely that the security will be generic too and dependant of database content.
Hope it help...

For the backend, i implemented a program which had a similar interaction with the database. the code was database structure oblivious, instead, it read a config file describing the db and could construct complex sql queries based on this information. most of the code is proprietary, but one bit of it got pushed into an open source project called sqlbuilder. may be useful to you on the backend.

I think you're on the right track, with your tool seclection. Your 100% data driven model is going to be hard to maintain. But I understand that's a requirement not an option. Normal source control is going to fail you becuase of the ui application logic all being in the meta-data. You'll need some good test databases and some way to maintain them, such as regularily mysqldump them out and check them in to souce code control to handle all the differences, etc..
You're wise to stay away from various ORM solutions and just use JDBC for this type of app.
Let me give you some warnings about GWT. On the surface it will abstract all the uglyness of html, javascript away and give you clean heirarchy's BUT...
1) If the abstraction fails you how do you easily debug?
2) Do you want any of your site to be visible to Google or other search engines, if yes GWT is not for you
3) Do you want to use any HTML5 technogies or do you want to be stuck in IE 5 compatability mode?
So...
I think you'll be much better off Implementing the UI as simple HTML controls with a small set of jQuery ajax interactions with the server. You can define an input type in your database, your serverlet can generate an input tag and then you have two options you can have some standard event bindings in jquery to tell your server that button1. is clicked, or that select2 has changed, etc.
Your server can send back javascript to change the state of the ui - simply load the javascript inside a div so it runs on the client. or 2) You let the input submit the data to the server and do an old school page refesh and the servlet build the next ui screen based on the database.
Building an interface dynamically in HTML from a database is easy and straight foward compared to doing the same in SWING or Windows Forms. You just have to write out a big text string, been doing that since 1999.
That approach is going to be much more lightweight - simpler to debug, understand and modify in the long run than going with the "GWT automatically compiles to unreadable javascript that doesn't run in my browser for some unknown reason" solution.

Choices for smartphone accessibility of pre-existing vb.net/sql server desktop crud application

The application is vb.net front end and sql server express backend. The networks are always cabled LANs.
Installations are small with only a few users, none of whom would have any technical knowledge.
Very little technical support is ever called for and I'd like to keep it that way.
I don't know Java or Objective C or HTML/CSS/Javascript which as far as I can see seem to be the choices for smartphone development on Android, iphone or web based application
I want users to be able to access as much of the functionality of the application as possible for the least effort both in terms of coding and acquiring new skills on my part.
I don't know where to start or which would provide the easiest path.
I don't know how to make the database available to smartphones whilst keeping it physically secure in a small office.
If all things were equal I'd probably learn towards HTML/CSS?Javascript as it seems to be the most widely applicable.
On the other hand maybe I should wait for win phone 7?

To reach the largest number of users in a device independent manner then delivery via browser is going to give you the best results for the least effort.
If you have designed you existing application with a Data Access Layer, a Business Rules Layer and a User Interface layer, this may be as simple as creating an ASP.NET UI for mobile/internet/intranet users.
If your appliciaction is not designed this way, then my approach would be to seperate out the code in you existing into these three layers, or at the very least seperate the UI layer out of the existing code. Then it just a matter of implementing a UI layer for each access method you plan to use.
That way you end up with a lot less code to maintain, and when the businees rules or backend data changes you only have to do the change in one place for all you User Interfaces.

Well, .NET Compact Framework is already avaialbe on WinMobile, so you defenitely should give it a try if you're free to choose which mobile OS to target.
If not, I suppose that for task like this it would really be better to use web interface. If you don't now HTML/CSS/JS - as for me it's not a problem but a great chance to learn new interesting trendy things! :)

I would go with a simple html app designed for a mobile screen.
Android or iphone will only get a % of your users. If you want to get them all, you would need to write in both (and then blackberry and winmo are SOL).
So without seeing the application, it is very hard to know how much work converting vn.net to something you can get at from a web browser would be... but I don't think it would be much worse than a port to android or iphone, and it will allow a much bigger market to view.
Either way, you will need to learn something new. Learning is good though, right?

How do I decide between a using a Swing GUI or a light-weight web client for the user front end of my Java application?

I always seem to have this internal struggle when it comes to user interface. I build up an application "engine" and tend to defer user interface to after I get my algorithms working. Then I go back and forth trying to decide how to let a user interact with my program. Personally, I'm a fan of the command line, but I can't expect that of my users generally.
I really like what's possible in the browser in the age of web 2.0 and ajax. On the other hand it's not so hard to make a Swing front-end either, and you can generally count on a more consistent presentation to the user (though using a good javascript framework like YUI or jQuery goes a long way toward normalizing browsers).
Clearly both approaches have their merits and drawbacks. So, what criteria / parameters / situations should lead me to use a lightweight (e.g. web-based) GUI? What criteria / parameters / situations should lead me to use a heavier (e.g. Swing-based) GUI?
It is not my intent to start a flame war, merely interested in the community's constructive/objective opinions.
Edit #1
In light of the first few responses, I would like to clarify that I would like to deploy my application regardless, not host it on some internet server necessarily. So I would have to deploy with a light-weight web-server infrastructure a la Jetty/Tomcat or similar.

It depends on the application and this is essentially a usability driven question (though there are considerations like data storage and platform requirements). Think of the pros and cons.
Pros of a lightweight Web UI:
Ease of distribution
Platform independent
Ease of maintenance
Cons of a lightweight Web UI:
Less environmental control
Markup standards vary between browsers
Requires a web server and everything that goes with it
Pros of an executable UI
More environmental control (i.e.: full screen applications, etc)
Not necessarily subject to latency and outages
Cons of an executable UI
Pushing updates may be more difficult
Requires installation
Potential platform requirements (frameworks, packages, etc)
Potentially requires knowledge of advanced networking topics (web services, etc)

One small factor you may want to consider is that the user will have go through some type of installation (albeit minimal) if you distribute a swing application.
Also a web application will allow you to accurately track the usage of your application (via google analytics or something similar). Not sure if that's a concern but it may be useful to you in the future.

If it is a client-server application I would normally go for a web frontend for the application.
You will save yourself of countless problems with things like installed JRE versions, distributing upgrades, application permissions, disappeared shortcuts...

You need to break the requirements of the application down to decide this...
Do the users have Java of sufficient version installed? It will need to be, to run a Swing GUI.
Do you have a web server?
Do you need the flexibility of a Swing GUI or the accessibility of the web interface?
Is Java Webstart and option, if so, you can distribute a Swing GUI via the web.
Does your application perform extensive calculations or processing? If so, a client app may be the answer.
There are a million questions such as these. I would suggest a brain storming session and keeping track of all the pros and cons of each, adding a point score, than throwing it all away and going with your gut feeling :)

If you anticipate there being frequent updates to the app then web based may be better since the user would not have to update the client or install a new client containing the updates.
If you think that the user may need the ability to use the app while not conencted to the internet then swing would be better.
Just two things off the top of my head.

Think about the users and use cases of your project.
Do users expect to have access to it when they're disconnected from the Internet (for example, on an airplane or in a coffee shop with no Internet access)? Use Swing.
Do you want users to be able to access the same tool from different computers (for example, both at work and at home)? Use a web UI.
Also consider whether the user needs to save and load data, and whether the tool produces data files that some might consider sensitive (if so, storage on the web might be an issue).

Do make a quick guess I often try to ask myself/customers if the application has a high "write" demand.
For a mostly read-only application a thin-client solution is perfectly well suited.
But if a lot write actions are needed then a swing desktop application has more flexibility.
Personally I always prever a swing desktop application. It can easily deployed using Java Webstart.

Not knowing anything about your application I can not give the best recommendation possible. However I can state from personal/professional experience that installing an application on clients machines is a LOT more of a pain in the ass than it seems.
With AJAX/web you really only have to worry about supporting like three browsers. Installation messes/updates are only felt once when you deploy the product to the web server.
With like a stand-along Swing app, you get to deal with the really really big mess that is installing the application onto unknown systems. This mess was so bad that things like AJAX were really pushed along to make web apps behave/feel like a real native app.