These are quite a few questions and probably not to be answered in one go. I am sure everything you want to do can be done.
There are several steps needed and first of all break the task into smaller tasks. The first thing to note is that most operations can be done in several different ways and if you have a problem because one operation is taking long then you have to look at alternatives. So everyone involved with the project need to adjust to the task at hand and learn it in steps. As you have already discovered then innocent looking statements can make the system freeze if it involves a huge number of operations. That is way while learning you should experiment with small number of data and that is of course true of any system in any language. J can handle a huge number of data so that is not a problem and it can handle a lot of connections. I do not think J will be a problem but the learning curve of the people involved should be considered. Once everyone is up to speed I do not see any problem you should not be able to do what you want. 2010/6/10 Stefan Scott Alexander <[email protected]>: > Hi - > > I see a lot of client-server database applications where a Java client > interacts with an SQL database server via an application server such as > JBoss. > > This is a popular architecture, but in many situations requiring only some > basic CRUD operations and some simple notions of workflow, it seems to have > several drawbacks: > > - slow performance, due to the multiple tiers, multiple languages, big > libraries (JAR files) being loaded, row-oriented (versus column-oriented) > nature of most commercial RDBMSs > > - difficult to customize on-the-fly, due to static typing on the Java side > and the traditional split between DDL and DML on the SQL side > > I'm still rather new to J, but I'm impressed with many of its features: its > simplicity, performance, its dynamic/interpreted nature, the small size of > its interpreter and code, and the possibility of coding both the front end > and back end of a system using a single language: J. > > So I'm interested in hearing people's opinions as to whether J is suitable > for mid-size client-server database application development, as an > alternative to more traditional architectures such as Java+SQL+JBoss - in > terms of run-time performance, customizability, and programmer efficiency. > > > Would it make sense, from a practical standpoint, to port a typical, > mid-size Java+SQL+JBoss application to J (involving roughly 500 tables, with > roughly a million records and 100 columns in the biggest table)? > > Would there be any serious "gotchas" I'd run into eventually - features that > are considered standard in polished client-server database apps which would > be difficult or impossible to implement using J? I haven't probed all the > ins and outs of J yet, so I'm still not sure whether I'd be able to use it > to satisfy practical real-world requirements such as the following: > > - implement some sort of concurrency mechanism to handle situations where > multiple users might be trying to write the same record at the same time > > - ensure database ACID properties > > - provide a rich user interface including things like: > - - - grids having custom cell editors (eg, a calendar control in a date > cell, a multi-column combo-box control in a cell referencing a foreign key, > maybe even a graphic in a cell), "freezable" left-hand grid columns, etc. - > perhaps by adding some additional OCX controls. [Even though OCX controls > are compiled separately, would J602 still be able to manipulate them > dynamically?] > - - - a user-friendly visual query builder similar to the one in MS-Access > > - handle large numbers of simultaneous connections efficiently in terms of > memory space usage and CPU usage > > - support updatable views without too much hassle > > If people are of the opinion that J could satisfy these sorts of practical > real-world requirements (plus any other major ones I may have left out) > roughly as well as, say, Java+SQL+JBoss could, then I might be interested in > rolling up my sleeves and attempting to do some real-world programming J. > > Maybe I could start off by porting some existing medium-sized open-source > database application from Java+SQL to J, initially targeting just the > Windows platform for deployment. I realize that everything's browser-based > these days, and J701 may be dropping support for the native Windows GUI, but > using J602 to target just Windows as a client platform could still make > sense for two reasons: the continued widespread use of Windows, and the > remarkable ability of J602's interpreter to dynamically manipulate native > Windows forms and controls. > > The examples below which I've been playing with seem to indicate that J (and > its libraries) can already provide much of the basic infrastructure needed > for building client-server database systems: > > http://www.jsoftware.com/jwiki/JDB > http://www.jsoftware.com/jwiki/JDB/ClientServer > http://www.jsoftware.com/jwiki/JDB/Browser > > Again, my concern is whether these sorts of simple examples would "scale" > well to mid-size, real-world applications. I noticed, for example, that when > I loaded the (million-record) Vehicle Registration table into the Browser > example above, J seemed to freeze. But maybe the example was using a regular > grid, and it would perform better if a virtual grid were used instead. Since > J can be used to implement column-oriented rather than row-oriented > databases, I'm not too worried about J's performance as a "calculation > server". I guess what I'm more worried about, as mentioned above, are other > features like concurrency, rich user interface, scaling to large numbers of > connections - the kinds of nice-to-have features which users have come to > expect in polished, professional real-world applications. > > > Intuitively, the roadmap for such a project seems fairly clear-cut: rewrite > the RDBMS tables and views from SQL to J, rewrite the client from Java to J, > and rewrite the server from Java to J. I'm hoping that the payoff would be a > new sort of client-server database application: one which is fast and > compact and easy to customize, maybe even to some degree by end-users at > runtime. > > Does that make sense? Am I missing any major pieces of the puzzle here? > > I'm still rather new to J. On the one hand, I don't want to overly idealize > it, imagining that it can do all kinds of things it can't do. But on the > other hand, what I've seen so far about J is really impressive - not only > for its ability to handle vector data compactly and quickly without looping, > and for its powerful algebra of functions, but also for the runtime > customization possibilities which I suspect it could offer due to the fact > that it's interpreted, and the simplicity and flexibility which would result > from being able to program all tiers of a client-server system in just one > interpreted language rather than in several compiled ones. > > Is there any reason (other than lack of awareness about J) why a real-world > mid-size client-server database couldn't be successfully implemented in J > versus more traditional approaches like Java+SQL? As I said earlier, a lot > of the big database apps out there is just CRUD + workflow, and it seems > like J could easily do this, while also providing much more compactness, > efficiency, simplicity, and customizability. > > Thanks for any advice. > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > -- Björn Helgason, Verkfræðingur Fornustekkum II 781 Hornafirði, t-póst: [email protected] gsm: +3546985532 sími: +3544781286 http://groups.google.com/group/J-Programming Tæknikunnátta höndlar hið flókna, sköpunargáfa er meistari einfaldleikans góður kennari getur stigið á tær án þess að glansinn fari af skónum /|_ .-----------------------------------. ,' .\ / | Með léttri lund verður | ,--' _,' | Dagurinn í dag | / / | Enn betri en gærdagurinn | ( -. | `-----------------------------------' | ) | (\_ _/) (`-. '--.) (='.'=) ♖♘♗♕♔♙ `. )----' (")_(") ☃☠ ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
