[Vtigercrm-developers] MySQL Migration Tool

[Dhr. R.R. Gerbrands]

Hi all,

Well I agree partly, as MYSQL isn't the only database in place! As  
their are some who work with postgrssql instead, not to mention the  
possibility for Oracle or anything else.
If it's a tool to be used by many other sql databases fine, but as  
far as I know it's not.

Refering to Dirk question why another tool, I've been developing with  
another tool: see www.radicore.org because I prefer a even stronger  
splitup: in using 3-tier design architecture.
Although until now it's only been for customisation of VtigerCRM, I  
would love to see the base of 3-tier which is allready within  
VtigerCRM taken a few steps futher.

Ton introduce it futher with a
[quote from radicore website:]
3-Tier Architecture

An architectural pattern of software development in which the  
application logic is separated into different tiers or layers:

The Presentation Layer or User Interface, which all handles all  
communication with the user.
The Business Layer, which has a separate object for each business  
entity.
The Data Access Layer which communicates with the database.
This allows individual layers to be enhanced, or even replaced, with  
minimal impact on the other layers. For example it should be possible  
to change nothing but the contents of the presentation layer in order  
to switch from XHTML output to PDF output, or to change nothing but  
the contents of the data access layer in order to switch from one  
database engine to another.

[end quote]

Best regards, Remco




Op 5-nov-2006, om 16:04 heeft Dirk Gorny het volgende geschreven:

> Am Sonntag, 5. November 2006 15:45 schrieb Ken Lyle:
>> I just discovered on my computer the MySQL Migration
>> Tool, 1.1.4 rc.
>
> Why another tool? The more code, the more errors. The basic thing  
> is to put
> one database struktur to annother. Our ancestry therfor developed  
> SQL. Long
> time ago with applications which where more complex in database  
> structure all
> things were done in SQL. This prevents of running out of memory or on
> timeouts by the *.php or whatever you use. And, the great benefit;  
> you will
> get meaningful error messages which are not dumped by the overlying  
> script.
> So my recommendation:
> Pure SQJ, as few as possible Loops and complex strukture.
> Not referencing by attribute order. Ever referencing by attribute.
> I know it is a boring idea, but for me it worked the last 20 Jears.
>
> Best regards,
>
> Dirk
> _______________________________________________
> Reach hundreds of potential candidates - http://jobs.vtiger.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20061105/4d7844fb/attachment-0004.html