Fabricio Mota <fabricio.mota@stripped> wrote on 11/16/2005 01:02:08 PM:
> Hi all again,
> I'm trying to deicide the best choice for clusters and servers
management.
> At the first specification, I suggested to manage it using *insert,
> update *and
> *delete *commands over 3 system tables (DDE_CLUSTER, DDE_SERVER and
> DDE_SERVER_CLUSTER).
> (old spec is in http://www.geocities.com/fmotaol/DDE/DDEspec.htm)
> But now, I'm thinking about the possibility to use specific commands
for
> manage it, such as:
> *create dde_cluster My_dde_cluster (
> 1 as 'mysql://dbserver.mysql.com:3306/mydb1' user root password 'test',
> 2 as local user root password 'test',
> 3 as 'mysql://anotherserver.mysql.com:3306/mydb1' user root password
'test'
> );*
> * *
> *subscribe 4 as 'mysql://fourthserver.mysql.com:3306/testdb' into
> My_dde_cluster user root password 'test';*
> *unsubscribe 4 from My_dde_cluster;
> *
> Despite it might increment a little bit the language parser, it could
> improve the usability.
> So, I would like to get this decision not based only in user-side, but
also
> in technical aspects, such as development cost and maintainibility.
> Waiting for suggestions, thank you since now.
> Regards,
> Fabricio Mota
>
>
> --
>
> Sem mais,
>
> Fabricio Mota
> Oda Mae Brown - Aprecie sem moderação.
> http://www.odamaebrown.com.br
You gain a lot of flexibility by moving from direct INSERT/UPDATE/DELETE
commands to a parsable grammar. A good example of this is the permissions
system. By using a single GRANT or REVOKE statement, you could affect
records in up to three tables at one time. Parsable statements and
commands isolate the user from changes in the implementation tables. MySQL
could completely redesign their permissions tables and no application that
managed user permissions with only GRANT or REVOKE statements would break.
If the application had been doing it's own INSERTs and such, then the
application would have to be redesigned in order to work with the new
permissions schema.
Even if it's a little more difficult to setup, you are much better off in
the long run creating the statement grammar and writing the parser
routines to interpret it than you will be if you force your users to
manage the cluster metadata directly.
That being said, in reference to your CREATE DDE_CLUSTER() example. It
makes as much sense to me to define an empty cluster and add servers to it
later as it does to add the servers when you create the cluster. Please
allow for the option of creating an empty DDE_CLUSTER. I think that if you
prefix all of your commands with "dde_" then you minimize the risk of
doing something unintentional.
CREATE DDE_CLUSTER ...
RECOGNIZE DDE_SERVER ... as serveralias;
SHOW DDE_CLUSTERS;
SHOW DDE_SERVERS;
ALTER DDE_CLUSTER clustername ADD MEMBER ...
ALTER DDE_CLUSTER clustername DROP MEMBER ...
ALTER DDE_CLUSTER clustername DEMOTE MEMBER ...
CREATE DDE_PARTITION partitionname ON servername AS ...
As you design your new commands, try to draw parallels from existing SQL
statements. That will make the learning curve for your new product much
easier. Don't forget, if you are going to make the DDE engine available on
v5.0+ that you will need to support the INFORMATION_SCHEMA views as well.
You can save that for later, though. It's not a priority to getting it
initially built.
Shawn Green
Database Administrator
Unimin Corporation - Spruce Pine
