Re: Visual FoxPro (VFP) 9 Migration Strategy to Postgresql on Linux
| От | Merlin Moncure |
|---|---|
| Тема | Re: Visual FoxPro (VFP) 9 Migration Strategy to Postgresql on Linux |
| Дата | |
| Msg-id | CAHyXU0ygcquV2Q+ofaaL43dZf1aCg7WurjQp2qCt=fcexYL3ZA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Visual FoxPro (VFP) 9 Migration Strategy to Postgresql on Linux ("Kevin Salisbury" <KSalisbury@twinman.com>) |
| Ответы |
Re: Visual FoxPro (VFP) 9 Migration Strategy to
Postgresql on Linux
|
| Список | pgsql-novice |
On Fri, Apr 13, 2012 at 10:41 AM, Kevin Salisbury <KSalisbury@twinman.com> wrote: > > We are in the early stages of planning a migration of all our VFP 9 databases to Postgresql. Our VFP dbc contains roughly300 tables and 8GB total data. Screen replacements are likely going to be HTML5/CSS3 based and report replacementswill likely be one of the open source BI reporting portals. While we know VFP very well, and we use a LOT oflinux elsewhere in the company - we know very little about Postgres. We do see a lot of tutorials out there for new Postgresdatabases, but not much in the way of migration from VFP. We're curious to know if anyone else has gone through asimilar migration that may have some advice on how to get started. I started out in foxpro and ended up in postgres. IMNSO, you're making the correct choice. In my case, I didn't go 'full web' right off the bat but went to a delphi-postgres thick client approach which remains, even today, the most efficient method of developing applications ever invented. There's a lot of ways to do web applications and how you do it will probably be a bigger mental switch than the backend database. Postgres can fortunately duplicate most of the things foxpro can do (in my case, it was functional indexes) and once you get used to the SQL paradigm things will feel easy, natural, and elegant. Being foxpro guys you'll probably be writing a lot of stored procedures (plpgsql, while quirky, is great for that) and keeping a lot of logic in the backend which is a good approach. On the web side, I would tend to avoid all technologies that employ scaffolding, or auto-generation, of either the html or the sql. Learning jquery is a fantastic choice for your client side javascript and it will open the door to many fantastic free/commercial rlibraries like jqueryui, jstree, highcharts, google maps, and the up'n'coming google charts. Take a very strong look at the new postgres json support (http://people.planetpostgresql.org/andrew/index.php?/archives/255-JSON-for-PG-9.2-...-and-now-for-9.1!.html) and how it can efficiently tie into json receiving javascript libraries. On the BI side, you can either do an ad hoc java script based solution or employ a reporting framework. If you want to go full framework then your best options are probably in the java side of things. The best of class reporting solutions are probably jasper for classic reports or Pentaho Mondrian for full BI. I prefer full javascript, but it's totally understandable if you want to use a framework especially if you want to make a heavy investment into java. There's also the expensive Smart framework which can either be used directly or via java through the GWT. Speaking of the GWT, while I think it's great for a heavy java team, I think you'll get more mileage out of javascript/html5/css if you're starting from scratch. Anyways, good luck. merlin
В списке pgsql-novice по дате отправления: