Auto sync with database

Discussion:

(too old to reply)

unknown

2007-02-14 15:57:33 UTC

Hi,

We use PowerDesigner (11.0.0.1270 Beta 1) to keep track of
about 100 schemas which are changed fairly often. We're
looking for a way to keep these schemas in sync with our DB2
and MySQL databases.

The ideal situation would be that whenever someone were to
open the PowerDesigner file, the program would automatically
reverse engineer the proper database connection and update
the schema. However, thus far I've been unable to find any
way to do that.

What we're trying to avoid is someone having to go through
each schema every week and manually do a reverse engineer so
that the file is up to date.

Does anyone know if something like this is possible?

Thank you,

Aric

Paul Horan[TeamSybase]

2007-02-14 19:42:16 UTC

Permalink

So they change the schema directly in the database, and are only using PD to
keep the documentation up to date??

Doesn't that seem... backwards to you? I would think that you'd want to
use PD to model the change, then drive the changes out into the database
itself. That way, the data model is always up to date.

Paul Horan[TeamSybase]

Post by unknown
Hi,
We use PowerDesigner (11.0.0.1270 Beta 1) to keep track of
about 100 schemas which are changed fairly often. We're
looking for a way to keep these schemas in sync with our DB2
and MySQL databases.
The ideal situation would be that whenever someone were to
open the PowerDesigner file, the program would automatically
reverse engineer the proper database connection and update
the schema. However, thus far I've been unable to find any
way to do that.
What we're trying to avoid is someone having to go through
each schema every week and manually do a reverse engineer so
that the file is up to date.
Does anyone know if something like this is possible?
Thank you,
Aric

unknown

2007-02-15 05:17:05 UTC

Permalink

I'm with Paul on this one.
The ideal is to use PowerDesigner to model the changes and push them out
to the databases.
If you are not doing that, but are only RE'ing the databases into PD as
a documentation step, then you have wasted a lot of money. There are a
number of DBA tools that scan the system tables and generate reports.
--
Mike Nicewarner [TeamSybase]
http://www.datamodel.org
mike[at]datamodel[dot]org (can you figure what to change?)
Sybase product enhancement requests:
http://www.isug.com/cgi-bin/ISUG2/submit_enhancement

Shao Chan

2007-02-15 09:09:30 UTC

Permalink

That's the ideal position to take, but in reality it seldom works that way.

If you create a new product and you are the main person making database
changes and anyone that does is skilled in Power Designer and you have a
reasonable inhouse procedure for maintaining which is the current document,
then yes, this is a good way to go.

However, in reality, many databases are from different technologies and have
their own tools. Many systems are designed using one tool and then that
might change over time when another DBA steps forward.

Depending on the way of working within the organisation, you may have
several people, some DBAs, some developers, etc making changes to the
database.

This is the reason why so many people like Sybase Power Designer's Reverse
Engineering capability. In fact, it is the prime component that I use.

But all of the above means that more often than not the process is to make
changes as required and then reverse engineer documents.

I currently am developing one system where our backend system uses Progress
database technologies. We have a central tier using Sybase ASA and handheld
clients using Ultralite. Because data is synchronised from the backend to
the central tier, the data model in both tiers is very similar.

Our working process for the backend is fairly formal and all database change
requests go through the database administrators. However, I control the
database administration to the ASA technologies, so what I have to work with
is different versions of the backend database.

I use Power Designer to reverse each of them and change them to ASA syntax
and if I need a diff, I use Power Designer to achieve that also.

I don't know many organisations that really use tools such as Power Designer
in the way it is intended to be used. Maybe 10 years ago, but not today.
In todays world with so many people skilled in different tools, people
moving around a lot, integrating with many different technologies, flexible
ways of working (many people making DB changes), and changing of tools used
to administer database changes, it is unlikely in my experience that Power
Designer or any tool will be used in such a manner other than initially at
the start of a project.

Cheers,

Shao

Post by unknown
I'm with Paul on this one.
The ideal is to use PowerDesigner to model the changes and push them out
to the databases.
If you are not doing that, but are only RE'ing the databases into PD as a
documentation step, then you have wasted a lot of money. There are a
number of DBA tools that scan the system tables and generate reports.
--
Mike Nicewarner [TeamSybase]
http://www.datamodel.org
mike[at]datamodel[dot]org (can you figure what to change?)
http://www.isug.com/cgi-bin/ISUG2/submit_enhancement

Paul Horan[TeamSybase]

2007-02-15 15:06:48 UTC

Permalink

This is more a discussion of philosophy, discipline, and "best practices"
than one of technology.

Clearly, the "best practice" is to use tools like PowerDesigner to model the
business/data/objects and to drive those models out into the software that
implements them, not the other way around... The Reverse Engineering
feature is *best* used to jump start the modeling process for systems that
are already constructed - not as a mechanism for keeping the "documentation
of the system" in sync with what's been deployed. That's a losing
proposition, as we ALL know that documentation is the last thing to get any
attention when timelines are short.

I came from a company that tried to do it the other way - developers would
design database changes right in the PB database painter - and I was always
the one that got asked "is the PDM up to date?". The fact that the question
was even being asked is an indication that something is very wrong with the
development lifecycle at that company.

It takes commitment at all levels (mgmt down to low-level developers) to
embrace model-driven development, but the end result is better quality
software.

My 2 cents.

Paul Horan[TeamSybase]

Post by Shao Chan
That's the ideal position to take, but in reality it seldom works that way.
If you create a new product and you are the main person making database
changes and anyone that does is skilled in Power Designer and you have a
reasonable inhouse procedure for maintaining which is the current
document, then yes, this is a good way to go.
However, in reality, many databases are from different technologies and
have their own tools. Many systems are designed using one tool and then
that might change over time when another DBA steps forward.
Depending on the way of working within the organisation, you may have
several people, some DBAs, some developers, etc making changes to the
database.
This is the reason why so many people like Sybase Power Designer's Reverse
Engineering capability. In fact, it is the prime component that I use.
But all of the above means that more often than not the process is to make
changes as required and then reverse engineer documents.
I currently am developing one system where our backend system uses
Progress database technologies. We have a central tier using Sybase ASA
and handheld clients using Ultralite. Because data is synchronised from
the backend to the central tier, the data model in both tiers is very
similar.
Our working process for the backend is fairly formal and all database
change requests go through the database administrators. However, I
control the database administration to the ASA technologies, so what I
have to work with is different versions of the backend database.
I use Power Designer to reverse each of them and change them to ASA syntax
and if I need a diff, I use Power Designer to achieve that also.
I don't know many organisations that really use tools such as Power
Designer in the way it is intended to be used. Maybe 10 years ago, but
not today. In todays world with so many people skilled in different tools,
people moving around a lot, integrating with many different technologies,
flexible ways of working (many people making DB changes), and changing of
tools used to administer database changes, it is unlikely in my experience
that Power Designer or any tool will be used in such a manner other than
initially at the start of a project.
Cheers,
Shao

Shao Chan

2007-02-15 15:57:30 UTC

Permalink

I think its also a discussion of working practices, increased integration
through a changing world and perception of what constitutes a new system.

There are areas in the database to add comments in the meta data for
documentation as well as using external documents. If you used Power
Designer to store this information, not only are you at the tool's mercy in
that you rely on the tool to be around for as long as the system you are
maintaining it with is around, but also you expect a lot more people to use
it than desired. In a large organisation, there is information about the
tables you may wish to detail that non-techies will want to see (or just
anyone really). If this is documented in an MS Word document, things are
fine, but not if you add things into Power Designer.

What happens if you need to change the tool? What if someone doesn't like
it or at least prefers another tool better? What if management no longer
want to pay for it? Commercially its both the best tool and the most
expensive tool around. Linux/Mac/other OS diehards will want to use a tool
that's cross-platform. Many will want to use a tool that's free. Java
diehards will want to use a plugin to the Eclipse framework. Academics will
want to use other tools they have used at Uni (is it still ERWin & Select
SSADM amongst others).

Whilst cross-platform PD excels, for maintaining each proprietory database,
there are the vendor's own tools which are usually pretty good also.

Then there's the issue of training people up on the tool and also with large
systems many people requesting database changes at the same time. You're
also relying that the tool will be correct all the time. This is not the
case, as the syntax generated is sometimes wrong depending on which set of
standards the database is following (e.g. do you define a BLOB as LVARCHAR
or LONG BINARY)?

Tools like PD are certainly excellent for seeing visually how the tables
relate and are good for reverse engineering DDL, but once the bulk of the
structure has been created, IMHO I am not sure that even with good
discipline, would I see tools like PD are the best way forward. The tools
were initially designed to do that, but its debateable as to whether you're
in a losing proposition if you don't. :)

Cheers,

Shao

Post by Paul Horan[TeamSybase]
This is more a discussion of philosophy, discipline, and "best practices"
than one of technology.
Clearly, the "best practice" is to use tools like PowerDesigner to model
the business/data/objects and to drive those models out into the software
that implements them, not the other way around... The Reverse
Engineering feature is *best* used to jump start the modeling process for
systems that are already constructed - not as a mechanism for keeping the
"documentation of the system" in sync with what's been deployed. That's a
losing proposition, as we ALL know that documentation is the last thing to
get any attention when timelines are short.
I came from a company that tried to do it the other way - developers would
design database changes right in the PB database painter - and I was
always the one that got asked "is the PDM up to date?". The fact that the
question was even being asked is an indication that something is very
wrong with the development lifecycle at that company.
It takes commitment at all levels (mgmt down to low-level developers) to
embrace model-driven development, but the end result is better quality
software.
My 2 cents.
Paul Horan[TeamSybase]

Post by Shao Chan
That's the ideal position to take, but in reality it seldom works that way.
If you create a new product and you are the main person making database
changes and anyone that does is skilled in Power Designer and you have a
reasonable inhouse procedure for maintaining which is the current
document, then yes, this is a good way to go.
However, in reality, many databases are from different technologies and
have their own tools. Many systems are designed using one tool and then
that might change over time when another DBA steps forward.
Depending on the way of working within the organisation, you may have
several people, some DBAs, some developers, etc making changes to the
database.
This is the reason why so many people like Sybase Power Designer's
Reverse Engineering capability. In fact, it is the prime component that
I use.
But all of the above means that more often than not the process is to
make changes as required and then reverse engineer documents.
I currently am developing one system where our backend system uses
Progress database technologies. We have a central tier using Sybase ASA
and handheld clients using Ultralite. Because data is synchronised from
the backend to the central tier, the data model in both tiers is very
similar.
Our working process for the backend is fairly formal and all database
change requests go through the database administrators. However, I
control the database administration to the ASA technologies, so what I
have to work with is different versions of the backend database.
I use Power Designer to reverse each of them and change them to ASA
syntax and if I need a diff, I use Power Designer to achieve that also.
I don't know many organisations that really use tools such as Power
Designer in the way it is intended to be used. Maybe 10 years ago, but
not today. In todays world with so many people skilled in different
tools, people moving around a lot, integrating with many different
technologies, flexible ways of working (many people making DB changes),
and changing of tools used to administer database changes, it is unlikely
in my experience that Power Designer or any tool will be used in such a
manner other than initially at the start of a project.
Cheers,
Shao

Post by unknown
I'm with Paul on this one.
The ideal is to use PowerDesigner to model the changes and push them out
to the databases.
If you are not doing that, but are only RE'ing the databases into PD as
a documentation step, then you have wasted a lot of money. There are a
number of DBA tools that scan the system tables and generate reports.
--
Mike Nicewarner [TeamSybase]
http://www.datamodel.org
mike[at]datamodel[dot]org (can you figure what to change?)
http://www.isug.com/cgi-bin/ISUG2/submit_enhancement

Paul Horan[TeamSybase]

2007-02-16 05:59:52 UTC

Permalink

In a large organisation, there is information about the

Post by Shao Chan
tables you may wish to detail that non-techies will want to see (or just
anyone really). If this is documented in an MS Word document, things are
fine, but not if you add things into Power Designer.

I disagree again, and quite wholeheartedly. Get the PowerDesigner Viewer.
It's free, and the more technical users can use that to browse the model in
read-only mode. For the less technical, you can use PD to produce Word or
RTF documents, or even HTML. We kicked out our data dictionary as an
internal website - one click deployment.

And who's creating those Word documents? Now you've got system metadata
stored in a tool that has no concept of how to effectively manage it... Or
worse - you've got some metadata in the PD repository and some elsewhere on
a random C: drive in a Word document.

Post by Shao Chan
What happens if you need to change the tool? What if someone doesn't like
it or at least prefers another tool better? What if management no longer
want to pay for it?

Importing and exporting models to other tools is 100% supported. (well, the
biggies like Erwin/Rose anyway. but those are at least as expensive, and
less functional than PD.)

Commercially its both the best tool and the most

Post by Shao Chan
expensive tool around. Linux/Mac/other OS diehards will want to use a
tool that's cross-platform. Many will want to use a tool that's free.
Java diehards will want to use a plugin to the Eclipse framework.

PD is already available as an Eclipse (and VS2005) plugin. And as far as
"free" goes - you get what you pay for... Don't come crying when the
support for that open-source tool is non-existent.

Academics will

Post by Shao Chan
want to use other tools they have used at Uni (is it still ERWin & Select
SSADM amongst others).

ERWin is being slowly poisoned to death by CA. They're certainly not
investing in its future. I'd bet money that it's a dead tool walkin'...

You're

Post by Shao Chan
also relying that the tool will be correct all the time. This is not the
case, as the syntax generated is sometimes wrong depending on which set of
standards the database is following (e.g. do you define a BLOB as LVARCHAR
or LONG BINARY)?

The syntax will be correct for the target DBMS and version. I've not heard
many reports that PD was generating incorrect syntax.
As far as the LONG BINARY vs. LVARCHAR issue - if you've got a reproduceable
case, please get it submitted...

Post by Shao Chan
Tools like PD are certainly excellent for seeing visually how the tables
relate and are good for reverse engineering DDL, but once the bulk of the
structure has been created, IMHO I am not sure that even with good
discipline, would I see tools like PD are the best way forward. The tools
were initially designed to do that, but its debateable as to whether
you're in a losing proposition if you don't. :)

Model-driven development doesn't stop with version 1.0 of your application,
and PD is SO much more than a means to visually present the schema... If
that's all you're using it for, just get Visio and save some cash...
There's impact analysis, naming convention rules, column domain consistency,
not to mention a full multi-user repository, with branching, versioning,
merging, reporting, etc...

Modeling is a strange paradigm - it's better to not do it at all than to do
it half-way...

-Paul-

Post by Shao Chan
I think its also a discussion of working practices, increased integration
through a changing world and perception of what constitutes a new system.
There are areas in the database to add comments in the meta data for
documentation as well as using external documents. If you used Power
Designer to store this information, not only are you at the tool's mercy
in that you rely on the tool to be around for as long as the system you
are maintaining it with is around, but also you expect a lot more people
to use it than desired. In a large organisation, there is information
about the tables you may wish to detail that non-techies will want to see
(or just anyone really). If this is documented in an MS Word document,
things are fine, but not if you add things into Power Designer.
What happens if you need to change the tool? What if someone doesn't like
it or at least prefers another tool better? What if management no longer
want to pay for it? Commercially its both the best tool and the most
expensive tool around. Linux/Mac/other OS diehards will want to use a
tool that's cross-platform. Many will want to use a tool that's free.
Java diehards will want to use a plugin to the Eclipse framework.
Academics will want to use other tools they have used at Uni (is it still
ERWin & Select SSADM amongst others).
Whilst cross-platform PD excels, for maintaining each proprietory
database, there are the vendor's own tools which are usually pretty good
also.
Then there's the issue of training people up on the tool and also with
large systems many people requesting database changes at the same time.
You're also relying that the tool will be correct all the time. This is
not the case, as the syntax generated is sometimes wrong depending on
which set of standards the database is following (e.g. do you define a
BLOB as LVARCHAR or LONG BINARY)?
Tools like PD are certainly excellent for seeing visually how the tables
relate and are good for reverse engineering DDL, but once the bulk of the
structure has been created, IMHO I am not sure that even with good
discipline, would I see tools like PD are the best way forward. The tools
were initially designed to do that, but its debateable as to whether
you're in a losing proposition if you don't. :)
Cheers,
Shao

Post by Paul Horan[TeamSybase]
This is more a discussion of philosophy, discipline, and "best practices"
than one of technology.
Clearly, the "best practice" is to use tools like PowerDesigner to model
the business/data/objects and to drive those models out into the software
that implements them, not the other way around... The Reverse
Engineering feature is *best* used to jump start the modeling process for
systems that are already constructed - not as a mechanism for keeping the
"documentation of the system" in sync with what's been deployed. That's
a losing proposition, as we ALL know that documentation is the last thing
to get any attention when timelines are short.
I came from a company that tried to do it the other way - developers
would design database changes right in the PB database painter - and I
was always the one that got asked "is the PDM up to date?". The fact
that the question was even being asked is an indication that something is
very wrong with the development lifecycle at that company.
It takes commitment at all levels (mgmt down to low-level developers) to
embrace model-driven development, but the end result is better quality
software.
My 2 cents.
Paul Horan[TeamSybase]

Post by Shao Chan
That's the ideal position to take, but in reality it seldom works that way.
If you create a new product and you are the main person making database
changes and anyone that does is skilled in Power Designer and you have a
reasonable inhouse procedure for maintaining which is the current
document, then yes, this is a good way to go.
However, in reality, many databases are from different technologies and
have their own tools. Many systems are designed using one tool and then
that might change over time when another DBA steps forward.
Depending on the way of working within the organisation, you may have
several people, some DBAs, some developers, etc making changes to the
database.
This is the reason why so many people like Sybase Power Designer's
Reverse Engineering capability. In fact, it is the prime component that
I use.
But all of the above means that more often than not the process is to
make changes as required and then reverse engineer documents.
I currently am developing one system where our backend system uses
Progress database technologies. We have a central tier using Sybase ASA
and handheld clients using Ultralite. Because data is synchronised from
the backend to the central tier, the data model in both tiers is very
similar.
Our working process for the backend is fairly formal and all database
change requests go through the database administrators. However, I
control the database administration to the ASA technologies, so what I
have to work with is different versions of the backend database.
I use Power Designer to reverse each of them and change them to ASA
syntax and if I need a diff, I use Power Designer to achieve that also.
I don't know many organisations that really use tools such as Power
Designer in the way it is intended to be used. Maybe 10 years ago, but
not today. In todays world with so many people skilled in different
tools, people moving around a lot, integrating with many different
technologies, flexible ways of working (many people making DB changes),
and changing of tools used to administer database changes, it is
unlikely in my experience that Power Designer or any tool will be used
in such a manner other than initially at the start of a project.
Cheers,
Shao

Post by unknown
I'm with Paul on this one.
The ideal is to use PowerDesigner to model the changes and push them
out to the databases.
If you are not doing that, but are only RE'ing the databases into PD as
a documentation step, then you have wasted a lot of money. There are a
number of DBA tools that scan the system tables and generate reports.
--
Mike Nicewarner [TeamSybase]
http://www.datamodel.org
mike[at]datamodel[dot]org (can you figure what to change?)
http://www.isug.com/cgi-bin/ISUG2/submit_enhancement

Shao Chan

2007-02-16 09:31:35 UTC

Permalink

Post by Paul Horan[TeamSybase]
I disagree again, and quite wholeheartedly. Get the PowerDesigner
Viewer. It's free, and the more technical users can use that to browse the
model in read-only mode. For the less technical, you can use PD to
produce Word or RTF documents, or even HTML. We kicked out our data
dictionary as an internal website - one click deployment.

Okay, now lets say you were an Oracle house using Oracle tools and they
rather not use Sybase tools.....what then? I am not saying that this is not
the ideal position to be in - I am saying that the driving forces in the
organisation say otherwise. With the PowerDesigner tools you can do a lot
more than just model the database, but to what extent should one depend on
the tool to store documentation and scripts?

Post by Paul Horan[TeamSybase]
And who's creating those Word documents? Now you've got system metadata
stored in a tool that has no concept of how to effectively manage it...
Or worse - you've got some metadata in the PD repository and some
elsewhere on a random C: drive in a Word document.

Okay, so let's say that your company then got taken over and all documents
needed their templates to change. This is a manual admin job. Are you
going to then let your admin team let loose on your PD documents which
control database schema to reformat any templates or are you going to try
within PD try to change the template - I am not sure how this works within
PD - does it pick up a separate template or do you apply the formatting
within PD? But you get the gist of what I am saying. Each document has
ownership but others can be involved from other business departments for
example if you needed to export schemas out in a format for the customer.

Post by Paul Horan[TeamSybase]
Importing and exporting models to other tools is 100% supported. (well,
the biggies like Erwin/Rose anyway. but those are at least as expensive,
and less functional than PD.)

To what extent? Certainly with DDL you can have the other tools reverse
engineer the database themselves, but for PD to be useful, it has to be
proprietory in some way and store information locally that does not map to
other tools in quite the same way. What happens when certain features don't
map?

Post by Paul Horan[TeamSybase]
PD is already available as an Eclipse (and VS2005) plugin. And as far as
"free" goes - you get what you pay for... Don't come crying when the
support for that open-source tool is non-existent.

That's always the argument with free tools, hence I don't depend on them
either, although others would want to head in that direction.

Post by Paul Horan[TeamSybase]
ERWin is being slowly poisoned to death by CA. They're certainly not
investing in its future. I'd bet money that it's a dead tool walkin'...

Glad you mentioned that. If ERWin can die, so can PD. Unless you control
the business of Sybase, you cannot be sure of the product direction and
investment of the tool.

Post by Paul Horan[TeamSybase]
The syntax will be correct for the target DBMS and version. I've not
heard many reports that PD was generating incorrect syntax.
As far as the LONG BINARY vs. LVARCHAR issue - if you've got a
reproduceable case, please get it submitted...

My point was that we use DDL first and rely on PD second rather than
regenerate the data model trying to find out which values to substitute. We
have databases that the PD does not support and so relying on such a tool
becomes less beneficial unless you only make use of the mass produced
databases. Changing syntax after exporting SQL in ODBC 3.0 compliant DDL is
an additional step that has to be taken.

Post by Paul Horan[TeamSybase]
Model-driven development doesn't stop with version 1.0 of your
application, and PD is SO much more than a means to visually present the
schema... If that's all you're using it for, just get Visio and save some
cash... There's impact analysis, naming convention rules, column domain
consistency, not to mention a full multi-user repository, with branching,
versioning, merging, reporting, etc...

I know. And you're saying that all this can be inter-changed to all the
other tools and vice-versa even when they may/may not have that
functionality and/or not support it in the same manner? Why would an
organisation wish to depend on PD to do this? To get to that level, people
need to know a lot about PD. Just using the Reverse Engineering and diffing
tools enables most people to get a lot of gain with very little knowledge
and dependency on the tool.

Post by Paul Horan[TeamSybase]
Modeling is a strange paradigm - it's better to not do it at all than to
do it half-way...
-Paul-

I agree with what you say, but your arguments, whilst it may support a tool
of some kind, does not suggest why it has to be PD. Furthermore, with the
other issues raised with using such a tool in the long term and with a
system that is not in isolation and the various other issues I raised, in
many real world environments I cannot tell people to use PD except during
the design of a new project. The benefits long term diminish.

Cheers,

Shao

Paul Horan[TeamSybase]

2007-02-17 00:42:20 UTC

Permalink

Post by Shao Chan
Okay, now lets say you were an Oracle house using Oracle tools and they
rather not use Sybase tools.....what then?

Then I'd say "you want me to build a skyscraper with tools that are best
suited for constructing doghouses?" Oracle's tools SUCK, and everyone knows
it (hence the prevalence of Quest's TOAD), but Oracle always throws them in
for free, and pointy-haired managers LOVE that number zero. They'll gladly
take free software and then spend three times the manhours. Idiots...

Post by Shao Chan
Okay, so let's say that your company then got taken over and all documents
needed their templates to change. This is a manual admin job. Are you
going to then let your admin team let loose on your PD documents which
control database schema to reformat any templates or are you going to try
within PD try to change the template - I am not sure how this works within
PD - does it pick up a separate template or do you apply the formatting
within PD?

You change the report template in PD (none of the models, just the report
template), and re-generate the documentation.

Post by Shao Chan
My point was that we use DDL first and rely on PD second rather than
regenerate the data model trying to find out which values to substitute.
We have databases that the PD does not support and so relying on such a
tool becomes less beneficial unless you only make use of the mass produced
databases. Changing syntax after exporting SQL in ODBC 3.0 compliant DDL
is an additional step that has to be taken.

If PD is generating incorrect syntax for a supported DBMS, and you can
reproduce this behavior, please submit a case! I'd personally love to see
this myself. If it's for a non-supported DBMS, then of course PD isn't
going to of any value. Just out of curiousity, which DBMS are we talking
about, and which version of PD?

Post by Shao Chan
Glad you mentioned that. If ERWin can die, so can PD. Unless you control
the business of Sybase, you cannot be sure of the product direction and
investment of the tool.

Well, if that's your logic, then MICROSOFT and ORACLE can die as well...
Sybase is completely committed to PowerDesigner, and the company is strong.
Neither are going to die within a reasonable management timeframe. I *do*
have some insight into company and product direction, and you can trust me -
this point is moot.

Post by Shao Chan
I agree with what you say, but your arguments, whilst it may support a
tool of some kind, does not suggest why it has to be PD. Furthermore,
with the other issues raised with using such a tool in the long term and
with a system that is not in isolation and the various other issues I
raised, in many real world environments I cannot tell people to use PD
except during the design of a new project. The benefits long term
diminish.

Then the point we're debating is whether or not to abandon modeling after a
system goes 1.0. I say that's foolish, and you think it's foolish to
continue beyond that point. I also see the value in modeling the "current
state" of software already in production - not everything down to the Nth
object class and most miniscule business process, but certainly the data
model and some basic UML diagrams.

If there's any value at all in modeling, then PD is ALREADY the industry
leader in data modeling (according to Gartner), and is rapidly establishing
a reputation in the other disciplines (OOM/UML, BPM, XML, Requirements).
The benefits only diminish if the commitment to the modeling discipline
diminish. One leads the other, and it's certainly not the tool's (or
Sybase's) fault...

-Paul-

Shao Chan

2007-02-20 14:14:41 UTC

Permalink

Post by Paul Horan[TeamSybase]
Then I'd say "you want me to build a skyscraper with tools that are best
suited for constructing doghouses?" Oracle's tools SUCK, and everyone
knows it (hence the prevalence of Quest's TOAD), but Oracle always throws
them in for free, and pointy-haired managers LOVE that number zero.
They'll gladly take free software and then spend three times the manhours.
Idiots...

Hi Paul, maybe I should have phrased it, what if you worked for Oracle. My
point was that there are factors out there that determine how much of a tool
that you used. The Oracle example was meant to be for Sybase internal
people to understand how realworld commercial reasons could affect
choice/change of tool. An Oracle house will PD, but Oracle themselves
probably will not. Most customers are Oracle because they have largest
market share of the database market.

Cheers,

Shao

unknown

2007-02-16 06:03:58 UTC

Permalink

Well, I've worked at a number of very large companies that have
completely embraced model driven design. We would never allow anyone to
just make changes to the database without going through a formal process
to make sure the changes are accurate to the requirements.

The decision to go with a tool like PD is pretty easy when you consider
the cost of poor data design. Remember that you can export metadata
from the models in a number of formats, like HTML, XMI, RTF/DOC, etc.
You can also just use the free (as in free beer) PD Viewer to let an
unlimited audience view the model information, in its entirety, if
desired. Oh, and XMI can be used to export the metadata to other
modeling tools.

You mention Eclipse. PD integrates very well with Eclipse, and the OOM
is very nice for those Java developers. This gives an incredible
functionality to keep data and code in sync.

If you only use the PDM to RE the DDL, then you are missing out on so
much more of the tool. Capturing business requirements, data analysis,
object modeling, process modeling, etc are all strengths in PD.
--
Mike Nicewarner [TeamSybase]
http://www.datamodel.org
mike[at]datamodel[dot]org (can you figure what to change?)
Sybase product enhancement requests:
http://www.isug.com/cgi-bin/ISUG2/submit_enhancement

Post by Shao Chan
I think its also a discussion of working practices, increased integration
through a changing world and perception of what constitutes a new system.
There are areas in the database to add comments in the meta data for
documentation as well as using external documents. If you used Power
Designer to store this information, not only are you at the tool's mercy in
that you rely on the tool to be around for as long as the system you are
maintaining it with is around, but also you expect a lot more people to use
it than desired. In a large organisation, there is information about the
tables you may wish to detail that non-techies will want to see (or just
anyone really). If this is documented in an MS Word document, things are
fine, but not if you add things into Power Designer.
What happens if you need to change the tool? What if someone doesn't like
it or at least prefers another tool better? What if management no longer
want to pay for it? Commercially its both the best tool and the most
expensive tool around. Linux/Mac/other OS diehards will want to use a tool
that's cross-platform. Many will want to use a tool that's free. Java
diehards will want to use a plugin to the Eclipse framework. Academics will
want to use other tools they have used at Uni (is it still ERWin & Select
SSADM amongst others).
Whilst cross-platform PD excels, for maintaining each proprietory database,
there are the vendor's own tools which are usually pretty good also.
Then there's the issue of training people up on the tool and also with large
systems many people requesting database changes at the same time. You're
also relying that the tool will be correct all the time. This is not the
case, as the syntax generated is sometimes wrong depending on which set of
standards the database is following (e.g. do you define a BLOB as LVARCHAR
or LONG BINARY)?
Tools like PD are certainly excellent for seeing visually how the tables
relate and are good for reverse engineering DDL, but once the bulk of the
structure has been created, IMHO I am not sure that even with good
discipline, would I see tools like PD are the best way forward. The tools
were initially designed to do that, but its debateable as to whether you're
in a losing proposition if you don't. :)
Cheers,
Shao

Post by Shao Chan
That's the ideal position to take, but in reality it seldom works that way.
If you create a new product and you are the main person making database
changes and anyone that does is skilled in Power Designer and you have a
reasonable inhouse procedure for maintaining which is the current
document, then yes, this is a good way to go.
However, in reality, many databases are from different technologies and
have their own tools. Many systems are designed using one tool and then
that might change over time when another DBA steps forward.
Depending on the way of working within the organisation, you may have
several people, some DBAs, some developers, etc making changes to the
database.
This is the reason why so many people like Sybase Power Designer's
Reverse Engineering capability. In fact, it is the prime component that
I use.
But all of the above means that more often than not the process is to
make changes as required and then reverse engineer documents.
I currently am developing one system where our backend system uses
Progress database technologies. We have a central tier using Sybase ASA
and handheld clients using Ultralite. Because data is synchronised from
the backend to the central tier, the data model in both tiers is very
similar.
Our working process for the backend is fairly formal and all database
change requests go through the database administrators. However, I
control the database administration to the ASA technologies, so what I
have to work with is different versions of the backend database.
I use Power Designer to reverse each of them and change them to ASA
syntax and if I need a diff, I use Power Designer to achieve that also.
I don't know many organisations that really use tools such as Power
Designer in the way it is intended to be used. Maybe 10 years ago, but
not today. In todays world with so many people skilled in different
tools, people moving around a lot, integrating with many different
technologies, flexible ways of working (many people making DB changes),
and changing of tools used to administer database changes, it is unlikely
in my experience that Power Designer or any tool will be used in such a
manner other than initially at the start of a project.
Cheers,
Shao

Post by unknown
I'm with Paul on this one.
The ideal is to use PowerDesigner to model the changes and push them out
to the databases.
If you are not doing that, but are only RE'ing the databases into PD as
a documentation step, then you have wasted a lot of money. There are a
number of DBA tools that scan the system tables and generate reports.
--
Mike Nicewarner [TeamSybase]
http://www.datamodel.org
mike[at]datamodel[dot]org (can you figure what to change?)
http://www.isug.com/cgi-bin/ISUG2/submit_enhancement

Shao Chan

2007-02-16 09:47:43 UTC

Permalink

To be fair, you can't put 'formal process' and 'PD' to mean one and the
same. For example, in our office, developers know how to use the schema
tools of the vendor of the database they are working with. They make the
database changes to a local database and submit a diff. All diffs are
loaded by one of the controlling DBAs of that system to a development
database.

A program written then scans for naming conventions and standards checking.
A combined diff is created for all the changes for that week and applied to
the database. This is then used as a diff for deployment to customers. The
diff can be checked by the DBAs and the before/after PD document can be
checked if so desired (or some other tool used) to ensure that the model is
not poorly done, but we have designers to assist in this at design time.

The point is that on a large system when we have many people requesting
changes to the system, we do not have one person with a PD document open
typing in all the changes. This is slow. Now I am not sure if PD enables
multiple people to have the document open at once, but once you've got
several thousand tables in the system and many teams expanding different
parts of the model, our approach is very good.

The decision to go with a tool like PD is pretty easy when you consider
the cost of poor data design. Remember that you can export metadata from
the models in a number of formats, like HTML, XMI, RTF/DOC, etc. You can
also just use the free (as in free beer) PD Viewer to let an unlimited
audience view the model information, in its entirety, if desired. Oh, and
XMI can be used to export the metadata to other modeling tools.

We use Sybase PD because it is commercially the best tool in the market and
I was happy when we started using iAnywhere technologies. But consider
this. If Sybase Power Designer was Oracle Power Designer and ERWin was
Sybase ERWin, where would you stand? Would you actually begin to appreciate
the realities that you cannot just argue on pure technical merit and that
using a competing database vendor's tool as the recommended way to manage
your own database might have adverse effects to public perception? Or would
the director's of Sybase more than happy to support and recommend a
competitor's product?

If you only use the PDM to RE the DDL, then you are missing out on so much
more of the tool. Capturing business requirements, data analysis, object
modeling, process modeling, etc are all strengths in PD.
Mike Nicewarner [TeamSybase]

I know that PD can do a lot even more so in the latest version. I have
never denied that. Neither am I saying that the best way forward to
architect a system is to do it without the aid of a tool. Neither am I
saying that a formal process should not be used.

I am saying that the formal process does not need to involve PD or any other
tool for that matter. I am saying that real world realities kick in when
considering the use of a tool and the tool should be used to get the maximum
gain with the minimum amount of effort. These areas are when starting a new
project and reverse engineering of products to get ERDs for customers to see
and to perform diffs. At least this is the case for us at present.

It's easy for Sybase people to say otherwise. The tool is theirs and the
only tool used in office immediately allowing disregard to other tools. It
happens to be the best tool on the market. There is no issue with cost.
The majority of databases which Sybase people work on will involve Sybase
databases. All the databases that Sybase people work on will probably be
supported by the tool. They have a direct order from Sybase to embrace and
encourage the use of their own products. The arguments are weighted
differently for people at Sybase.

I am not arguing technical merit for use of PD or ideal ways of working. PD
is a fine tool, but when balanced with everything else, its not all roses as
it is for Sybase people.

Cheers,

Shao

Paul Horan[TeamSybase]

2007-02-17 00:54:22 UTC

Permalink

Post by Shao Chan

Post by unknown
Well, I've worked at a number of very large companies that have
completely embraced model driven design. We would never allow anyone to
just make changes to the database without going through a formal process
to make sure the changes are accurate to the requirements.

To be fair, you can't put 'formal process' and 'PD' to mean one and the
same.

Of COURSE not - the tool alone doesn't force a process on you! The tool
only SUPPORTS the process! It's clear from your description that you've
developed a process that doesn't rely on any data modeling tools at all.
Introducing a tool like PD into that paradigm is going to fail, and that's
not PD's fault.

For example, in our office, developers know how to use the schema

Post by Shao Chan
tools of the vendor of the database they are working with. They make the
database changes to a local database and submit a diff. All diffs are
loaded by one of the controlling DBAs of that system to a development
database.
A program written then scans for naming conventions and standards
checking. A combined diff is created for all the changes for that week and
applied to the database. This is then used as a diff for deployment to
customers. The diff can be checked by the DBAs and the before/after PD
document can be checked if so desired (or some other tool used) to ensure
that the model is not poorly done, but we have designers to assist in this
at design time.

This can ALL be automated inside PowerDesigner, and you ensure model
consistency BEFORE any schema changes are implemented - even in the
developer's sandbox!

Post by Shao Chan
The point is that on a large system when we have many people requesting
changes to the system, we do not have one person with a PD document open
typing in all the changes. This is slow. Now I am not sure if PD enables
multiple people to have the document open at once, but once you've got
several thousand tables in the system and many teams expanding different
parts of the model, our approach is very good.

PD Enterprise ABSOLUTELY supports team development!!! Would ANY tool
survive if it forced an entire organization to be single-threaded??? The
repository features allow any developer to "extract" (check out) a document,
make their changes locally, generate out the "DIFF" SQL (or implement the
changes directly in their local DB), produce documentation for review, and
then consolidate their changes back into the repository - where other
developers can extract their changes to THEIR local workspaces.

Post by Shao Chan

Post by unknown
The decision to go with a tool like PD is pretty easy when you consider
the cost of poor data design. Remember that you can export metadata from
the models in a number of formats, like HTML, XMI, RTF/DOC, etc. You can
also just use the free (as in free beer) PD Viewer to let an unlimited
audience view the model information, in its entirety, if desired. Oh,
and XMI can be used to export the metadata to other modeling tools.

We use Sybase PD because it is commercially the best tool in the market
and I was happy when we started using iAnywhere technologies. But
consider this. If Sybase Power Designer was Oracle Power Designer and
ERWin was Sybase ERWin, where would you stand? Would you actually begin
to appreciate the realities that you cannot just argue on pure technical
merit and that using a competing database vendor's tool as the recommended
way to manage your own database might have adverse effects to public
perception? Or would the director's of Sybase more than happy to support
and recommend a competitor's product?

That's not the current state of the world, so why even bother with this
exercise? PD is #1 in data modeling. Period, end of story. It's better at
modeling Oracle databases than any of Oracle's tools - and that comes from
non-Sybase sources.

Post by Shao Chan

Post by unknown
If you only use the PDM to RE the DDL, then you are missing out on so
much more of the tool. Capturing business requirements, data analysis,
object modeling, process modeling, etc are all strengths in PD.
Mike Nicewarner [TeamSybase]

Again - not true. In actuality, the majority of PD customers are Oracle
shops.

All the databases that Sybase people work on will probably be

Post by Shao Chan
supported by the tool. They have a direct order from Sybase to embrace
and encourage the use of their own products. The arguments are weighted
differently for people at Sybase.
I am not arguing technical merit for use of PD or ideal ways of working.
PD is a fine tool, but when balanced with everything else, its not all
roses as it is for Sybase people.
Cheers,
Shao

Shao Chan

2007-02-20 14:20:32 UTC

Permalink

Post by Paul Horan[TeamSybase]
This can ALL be automated inside PowerDesigner, and you ensure model
consistency BEFORE any schema changes are implemented - even in the
developer's sandbox!

My point is that different departments have different working procedures and
they are not going to change simply because we find a tool we like. I use
Power Designer in our mobile projects as it was introduced by iAnywhere.
However, whilst I can recommend this tool to other teams, they are not going
to change their tool simply because Power Designer is the number one tool.

My point to this thread is that there are a lot more factors than pure
development as to how processes are run when getting database changes into
the system.

From a pure Sybase internal development perspect, the use of PD may be quite
clear, but that is not how it happens in the real world and there are good
reasons for it. PD is a good tool, but certainly I would only use it as
intended on a new project and it being a standalone database system at that.
Otherwise to me, there are far too many issues that get in the way to make
the tool worthwhile. This is why I am grateful that the Reverse Engineering
and diffing capabilities of the tool are there as it accommodates our way of
working which is neither better or worse than using the tool as a whole.

Cheers,

Shao

Paul Horan[TeamSybase]

2007-02-21 12:57:22 UTC

Permalink

I may work for Sybase now, but I'd spent over 20 years working in the "real
world" before joining up.

MY point to this thread is that your comments make it sound like the tool
itself is lacking in functionality, when (in my opinion) it's your
development processes (or lack thereof) that are incompatible with the use
of a "real world" modeling tool. You have to admit that what you're doing
cannot be considered "modeling" - it's more like "documentation of
post-deployment revisions to a physical DBMS", and those requirements, while
they might work for your organization, are no more indicative of "real
world" design/development methodologies.

While PD can definitely function in that role, it's easy to see how you
don't consider it a good fit for YOUR specific needs.

Paul Horan

Post by Shao Chan

Post by Paul Horan[TeamSybase]
This can ALL be automated inside PowerDesigner, and you ensure model
consistency BEFORE any schema changes are implemented - even in the
developer's sandbox!

My point is that different departments have different working procedures
and they are not going to change simply because we find a tool we like. I
use Power Designer in our mobile projects as it was introduced by
iAnywhere. However, whilst I can recommend this tool to other teams, they
are not going to change their tool simply because Power Designer is the
number one tool.
My point to this thread is that there are a lot more factors than pure
development as to how processes are run when getting database changes into
the system.
From a pure Sybase internal development perspect, the use of PD may be
quite clear, but that is not how it happens in the real world and there
are good reasons for it. PD is a good tool, but certainly I would only
use it as intended on a new project and it being a standalone database
system at that. Otherwise to me, there are far too many issues that get in
the way to make the tool worthwhile. This is why I am grateful that the
Reverse Engineering and diffing capabilities of the tool are there as it
accommodates our way of working which is neither better or worse than
using the tool as a whole.
Cheers,
Shao

Shao Chan

2007-02-21 16:51:23 UTC

Permalink

Hi Paul,

If my post implied that PD lacked functionality, then I do apologise. I
don't recall this to be the case, but I certainly would not want to be
misunderstood.

It is possible to model the database requirements without the need of a
tool. You may find that in some cases the tool enhances your productivity
especially if it fits into your way of working, but this is not always the
case.

In the past I have worked in organisations where there was one main
DBA/designer. Tools like this were excellent because only one or two people
required training in it, and it enhanced that persons maintaining of the
database by using the tool.

In my current organisation, whilst the role of the DBA is still fairly
clear, the design architects are varied and many. Not all will use tools.
Furthermore, developers are empowered to submit database changes and the
majority are simply an additional field here or there and do not affect the
structure of the database to any great extent. As said previously, once we
start using the tool to maintain multiple tiers, it is more effort when the
database technologies are different and hence we do not use it.

Cheers,

Shao

Post by Paul Horan[TeamSybase]
I may work for Sybase now, but I'd spent over 20 years working in the "real
world" before joining up.
MY point to this thread is that your comments make it sound like the tool
itself is lacking in functionality, when (in my opinion) it's your
development processes (or lack thereof) that are incompatible with the use
of a "real world" modeling tool. You have to admit that what you're doing
cannot be considered "modeling" - it's more like "documentation of
post-deployment revisions to a physical DBMS", and those requirements,
while they might work for your organization, are no more indicative of
"real world" design/development methodologies.
While PD can definitely function in that role, it's easy to see how you
don't consider it a good fit for YOUR specific needs.
Paul Horan

p***@itmatters.com.au

2007-02-19 01:54:26 UTC

Permalink

Dear Shao,
I have read the emails with interest and even though I don't
believe email is the best way to really share our beliefs
here, we also don't have the option of face-to-face so I
would just like to add a couple of comments without trying
the find the exact lines in the current emails.
For a start I am not part of Team Sybase and have got no
share in the company. When we evaluated PD a year back, I
could not even believe that Sybase as a company was still
alive. Marketing is probably the only place where CA beats
Sybase as fas as PD is concerned.
I have used Oracle Designer, ERwin, and now PD. PD is not
perfect but as Paul said is constantly being updated,
enhanced. ERwin is, I agree, dying of a slow death. They had
features which made sense for enteprise data modelling which
they removed.PD is still strong in France and I can't see
the product die for a long time.
As to framework and process we can't argue you definitely
have one in place. We can't argue on its suitability either
as we would need face-to-face and deep analysis of details.
This said, I am finding difficult to understand your issue
with using tools not knowing what the future will bring. If
you are using PD, yes, of course, you can change your report
look and feel very easily - using the RTF templace
capability. I am quite certain that we could address all of
your points of concern if we had more time and a better
communication means.
In the meantime, you are already using tools for your
process, PD is yet another tool which could improve your
process.

In one of my clients site we are developing an application
delivery framework based on enterprise modelling
(requirements, business process, and data modelling). We
made the decision early on that we would include PD as much
as possible unless proven unreasonable or unreliable. The
repository is multi-user, yes, we can branch, we can analyse
impact prior to change, we can report in many ways, yes
there is a free viewer, and a one-click deployment of
information in HTML format.

As far as using PD to modify an existing schema, there is
the archive file and modify database facility which I use
all the time and are reliable.

I think you should look into PD features in more details; I
would be surprised if you couldn't find more benefit to it
than just reverse-engineering.

Have a nice day
Pascale

"Mike Nicewarner" <"mike[at]datamodel[dot]org"> wrote in

Post by unknown
Well, I've worked at a number of very large companies
that have completely embraced model driven design. We
would never allow anyone to just make changes to the
database without going through a formal process to make

sure the changes are accurate to the requirements.
To be fair, you can't put 'formal process' and 'PD' to
mean one and the same. For example, in our office,
developers know how to use the schema tools of the vendor
of the database they are working with. They make the
database changes to a local database and submit a diff.
All diffs are loaded by one of the controlling DBAs of
that system to a development database.
A program written then scans for naming conventions and
standards checking. A combined diff is created for all
the changes for that week and applied to the database.
This is then used as a diff for deployment to customers.
The diff can be checked by the DBAs and the before/after
PD document can be checked if so desired (or some other
tool used) to ensure that the model is not poorly done,
but we have designers to assist in this at design time.
The point is that on a large system when we have many
people requesting changes to the system, we do not have
one person with a PD document open typing in all the
changes. This is slow. Now I am not sure if PD enables
multiple people to have the document open at once, but
once you've got several thousand tables in the system and
many teams expanding different parts of the model, our
approach is very good.

Post by unknown
The decision to go with a tool like PD is pretty easy
when you consider the cost of poor data design.
Remember that you can export metadata from the models

in a number of formats, like HTML, XMI, RTF/DOC, etc. You

Post by unknown
can also just use the free (as in free beer) PD Viewer
to let an unlimited audience view the model information
, in its entirety, if desired. Oh, and XMI can be used

to export the metadata to other modeling tools.
We use Sybase PD because it is commercially the best tool
in the market and I was happy when we started using
iAnywhere technologies. But consider this. If Sybase
Power Designer was Oracle Power Designer and ERWin was
Sybase ERWin, where would you stand? Would you actually
begin to appreciate the realities that you cannot just
argue on pure technical merit and that using a competing
database vendor's tool as the recommended way to manage
your own database might have adverse effects to public
perception? Or would the director's of Sybase more than
happy to support and recommend a competitor's product?

Post by unknown
If you only use the PDM to RE the DDL, then you are
missing out on so much more of the tool. Capturing
business requirements, data analysis, object modeling,
process modeling, etc are all strengths in PD. Mike

Nicewarner [TeamSybase]
I know that PD can do a lot even more so in the latest
version. I have never denied that. Neither am I saying
that the best way forward to architect a system is to do
it without the aid of a tool. Neither am I saying that a
formal process should not be used.
I am saying that the formal process does not need to
involve PD or any other tool for that matter. I am
saying that real world realities kick in when considering
the use of a tool and the tool should be used to get the
maximum gain with the minimum amount of effort. These
areas are when starting a new project and reverse
engineering of products to get ERDs for customers to see
and to perform diffs. At least this is the case for us at
present.
It's easy for Sybase people to say otherwise. The tool is
theirs and the only tool used in office immediately
allowing disregard to other tools. It happens to be the
best tool on the market. There is no issue with cost.
The majority of databases which Sybase people work on will
involve Sybase databases. All the databases that Sybase
people work on will probably be supported by the tool.
They have a direct order from Sybase to embrace and
encourage the use of their own products. The arguments
are weighted differently for people at Sybase.
I am not arguing technical merit for use of PD or ideal
ways of working. PD is a fine tool, but when balanced
with everything else, its not all roses as it is for
Sybase people.
Cheers,
Shao

Bryan

2007-02-19 16:27:32 UTC

Permalink

I've come late to this thread about the value of using PD (we seem to
have strayed from the original subject matter of auto-sync). Here's is
my opinion, having used PD since it was S-Designor, and also having
used ERwin and some other CASE tools (System Architect, Knowledgebase,
Silverrun etc.).

PD wins, in my opinion, because I can control the tool. Period.

My predominant experience is with a database that is not part of the
common set -- Oracle, SQL Server, DB2, etc. We have used NonStop SQL,
originally from Tandem now from HP, in a variety of forms.

PowerDesigner is the only tool that enables me to build my own
database definition. So I can construct a db definition that conforms
perfectly to the NonStop SQL syntax.

Beyond that, every client I work with has a different "site standard".
PowerDesigner lets me build DDL (or read DDL) that meets that
standard. It is simply a matter of creating a customize db definition.

And when NonStop SQL grew to SQL/MX (and its later descendants) with
new syntax and features, I didn't have to wait for Sybase to figure it
out -- I built one that worked and refined it over time.

ERwin never has, and never will, treat this database as a standard, so
there will never be ERwin support for this database. Their advice was
to use "generic ODBC" then make the revisions to the generated DDL by
hand....are you kidding?!?

Now I really like the rest of the PD product's features -- and I
understand the conceptual model approach as superior to ERwin's
"logical model" approach to data modeling that is database independent
(a PIM, in MDA-speak).

But the feature that wins the day for me -- and has for over 10 years
-- is that PD gives me control over everything I ask it to do.

--bryan

Shao Chan

2007-02-20 14:28:01 UTC

Permalink

Hi Pascale,

Thanks for the reply. No, we use the diffing tool as well. This is also
great. We also after Reverse Engineering use the tool to print out the
diagrams as they way it shows a gridline of how tables will be positioned
when printed is great.

I have always maintained that PD is the best tool around. The reason I
mentioned other tools was simply so that the Sybase Team could appreciate a
commercial dilemna if either their tool was no longer supported or if it
happened not to be the best tool around. It would not look good for Sybase
to use another database vendor's tool possibly.

Tools such as PD require training to make use of it to the tools best
capability. As your group grows more people need to understand and use the
tool. If developing multiple tier database systems, some of which are not
supported by PD and possibly some that are not SQL compliant, there can be
issues in using the tool once you move to the physical generation of the
schema. iAnywhere technologies involves synchronising databases on 2-3
different layers. There are some database changes and naming conventions
that might be needed at each layer and PD is not always the best option
forward.

Some people confuse the use of a tool such as PD with using a formal
process. It is possible to do one without the other.

You have a nice day too! :0)

Cheers,

Shao

Post by p***@itmatters.com.au
Dear Shao,
I have read the emails with interest and even though I don't
believe email is the best way to really share our beliefs
here, we also don't have the option of face-to-face so I
would just like to add a couple of comments without trying
the find the exact lines in the current emails.
For a start I am not part of Team Sybase and have got no
share in the company. When we evaluated PD a year back, I
could not even believe that Sybase as a company was still
alive. Marketing is probably the only place where CA beats
Sybase as fas as PD is concerned.
I have used Oracle Designer, ERwin, and now PD. PD is not
perfect but as Paul said is constantly being updated,
enhanced. ERwin is, I agree, dying of a slow death. They had
features which made sense for enteprise data modelling which
they removed.PD is still strong in France and I can't see
the product die for a long time.
As to framework and process we can't argue you definitely
have one in place. We can't argue on its suitability either
as we would need face-to-face and deep analysis of details.
This said, I am finding difficult to understand your issue
with using tools not knowing what the future will bring. If
you are using PD, yes, of course, you can change your report
look and feel very easily - using the RTF templace
capability. I am quite certain that we could address all of
your points of concern if we had more time and a better
communication means.
In the meantime, you are already using tools for your
process, PD is yet another tool which could improve your
process.
In one of my clients site we are developing an application
delivery framework based on enterprise modelling
(requirements, business process, and data modelling). We
made the decision early on that we would include PD as much
as possible unless proven unreasonable or unreliable. The
repository is multi-user, yes, we can branch, we can analyse
impact prior to change, we can report in many ways, yes
there is a free viewer, and a one-click deployment of
information in HTML format.
As far as using PD to modify an existing schema, there is
the archive file and modify database facility which I use
all the time and are reliable.
I think you should look into PD features in more details; I
would be surprised if you couldn't find more benefit to it
than just reverse-engineering.
Have a nice day
Pascale

"Mike Nicewarner" <"mike[at]datamodel[dot]org"> wrote in

Post by unknown
Well, I've worked at a number of very large companies
that have completely embraced model driven design. We
would never allow anyone to just make changes to the
database without going through a formal process to make

Post by unknown
The decision to go with a tool like PD is pretty easy
when you consider the cost of poor data design.
Remember that you can export metadata from the models

in a number of formats, like HTML, XMI, RTF/DOC, etc. You

Post by unknown
can also just use the free (as in free beer) PD Viewer
to let an unlimited audience view the model information
, in its entirety, if desired. Oh, and XMI can be used

Post by unknown
If you only use the PDM to RE the DDL, then you are
missing out on so much more of the tool. Capturing
business requirements, data analysis, object modeling,
process modeling, etc are all strengths in PD. Mike

Paul Horan[TeamSybase]

2007-02-21 13:02:55 UTC

Permalink

FYI: all of iAnywhere's databases are fully supported by PowerDesigner
DataArchitect.

And naming conventions can be enforced with the use of Extended Attributes
for the target database.

Yes, PD does require training to use. However, it's designed to support the
MODELING PROCESS! That implies that you understand the modeling process
before you can effectively use a tool whose purpose is to streamline your
implementation of those processes. If you're not modeling, then I can see
why you don't think PD is a good fit for you.

-Paul-

Post by Shao Chan
Hi Pascale,
Thanks for the reply. No, we use the diffing tool as well. This is also
great. We also after Reverse Engineering use the tool to print out the
diagrams as they way it shows a gridline of how tables will be positioned
when printed is great.
I have always maintained that PD is the best tool around. The reason I
mentioned other tools was simply so that the Sybase Team could appreciate
a commercial dilemna if either their tool was no longer supported or if it
happened not to be the best tool around. It would not look good for
Sybase to use another database vendor's tool possibly.
Tools such as PD require training to make use of it to the tools best
capability. As your group grows more people need to understand and use
the tool. If developing multiple tier database systems, some of which are
not supported by PD and possibly some that are not SQL compliant, there
can be issues in using the tool once you move to the physical generation
of the schema. iAnywhere technologies involves synchronising databases on
2-3 different layers. There are some database changes and naming
conventions that might be needed at each layer and PD is not always the
best option forward.
Some people confuse the use of a tool such as PD with using a formal
process. It is possible to do one without the other.
You have a nice day too! :0)
Cheers,
Shao

"Mike Nicewarner" <"mike[at]datamodel[dot]org"> wrote in

Post by unknown
Well, I've worked at a number of very large companies
that have completely embraced model driven design. We
would never allow anyone to just make changes to the
database without going through a formal process to make

Post by unknown
The decision to go with a tool like PD is pretty easy
when you consider the cost of poor data design.
Remember that you can export metadata from the models

in a number of formats, like HTML, XMI, RTF/DOC, etc. You

Post by unknown
can also just use the free (as in free beer) PD Viewer
to let an unlimited audience view the model information
, in its entirety, if desired. Oh, and XMI can be used

Post by unknown
If you only use the PDM to RE the DDL, then you are
missing out on so much more of the tool. Capturing
business requirements, data analysis, object modeling,
process modeling, etc are all strengths in PD. Mike

Shao Chan

2007-02-21 17:31:52 UTC

Permalink

Hi Paul,

I never said that any of iAnywhere's technologies were not supported by the
tool - please reread my thread.

Okay, scenario.

1)
We currently have a Progress OpenEdge 10 database:
http://www.psdn.com/library/kbcategory.jspa?categoryID=194

It is not currently a directly supported database of Power Designer and
therefore, any engineering to generate SQL code must default to selecting an
ODBC 3.0 compliant database. The issues with long binary etc, depends on
where people go for standards. I believe Progress go to:
http://developer.mimer.se/validator/index.htm
to determine their syntax but I understand that some syntax is not (or was
not given exact syntax in how it should be implemented).
Either way, whoever's fault it is, this means manual modification of the DDL
after it has been generated.

When modelling the database through PD, additional references, e.g. to
storage areas of whereabouts the table will sit need to be translated into
the terminology of the database. Again, the Progress RDBMS is not supported
by PD and therefore a fair amount of knowledge is required in PD to get it
to generate additional syntax (if at all possible).

2)
The above database is a backend database, whereas the mobile database is an
extension of one of the backend database modules. The backend database uses
procedures to limit names of tables/indexes to ensure compatibility with
Oracle. Also all tables created in the backend for the mobile project are
prefixed with 'mb' for mobile whereas there is no requirement for the mobile
SQL Anywhere ASA database.

Now, first of all the reason for the limit on table/indexes (each 14
characters) is because Oracle indexes have to be unique on the same database
schema. Therefore, within our Progress database working procedures (to
ensure our application can be run on an Oracle database), there is a limit,
so that when we convert the database, each index is held <table>##<index>.

Because of this, a table which is:
manufacturerRange
would become
mbManuRange

Those developing on the iAnywhere databases should not suffer the shortening
of the table such that it is more obscure. Therefore when generating the
schema for the iAnywhere databases, the full name is used, but for the
backend databases, the mb name is used.

Given that limits are imposed because of technology compatibilities there is
a requirement to:
1) Change syntax generated because of non-support of database by PD.
2) Change syntax generated because of table naming differences in each tier.

There is also something else I do not know how to do. The backend system is
the point of entry for database changes as this is the core system. The
Progress database provides its own tools for performing a diffs. We could
not use PD anyway because as far as I can tell, it can't tell the difference
between when a column is altered on the backend database (i.e. if I rename a
field). The field is dropped and a new one is put in its place than a
rename of the field.

Anyway, there are also a few other issues, but given the above, how would
you use PD? As far as I can tell, logically you would use PD at the backend
system as this will model the whole application. How much work is it to:
a) support all the proprietory features of the Progress RDBMS when
generating the DDL etc.
b) change the names of tables etc depending on when the syntax is exported
for the mobile database.

Cheers,

Shao

Post by Paul Horan[TeamSybase]
FYI: all of iAnywhere's databases are fully supported by PowerDesigner
DataArchitect.
And naming conventions can be enforced with the use of Extended Attributes
for the target database.
Yes, PD does require training to use. However, it's designed to support
the MODELING PROCESS! That implies that you understand the modeling
process before you can effectively use a tool whose purpose is to
streamline your implementation of those processes. If you're not
modeling, then I can see why you don't think PD is a good fit for you.
-Paul-

Post by Shao Chan
Hi Pascale,
Thanks for the reply. No, we use the diffing tool as well. This is also
great. We also after Reverse Engineering use the tool to print out the
diagrams as they way it shows a gridline of how tables will be positioned
when printed is great.
I have always maintained that PD is the best tool around. The reason I
mentioned other tools was simply so that the Sybase Team could appreciate
a commercial dilemna if either their tool was no longer supported or if
it happened not to be the best tool around. It would not look good for
Sybase to use another database vendor's tool possibly.
Tools such as PD require training to make use of it to the tools best
capability. As your group grows more people need to understand and use
the tool. If developing multiple tier database systems, some of which
are not supported by PD and possibly some that are not SQL compliant,
there can be issues in using the tool once you move to the physical
generation of the schema. iAnywhere technologies involves synchronising
databases on 2-3 different layers. There are some database changes and
naming conventions that might be needed at each layer and PD is not
always the best option forward.
Some people confuse the use of a tool such as PD with using a formal
process. It is possible to do one without the other.
You have a nice day too! :0)
Cheers,
Shao

"Mike Nicewarner" <"mike[at]datamodel[dot]org"> wrote in

Post by unknown
Well, I've worked at a number of very large companies
that have completely embraced model driven design. We
would never allow anyone to just make changes to the
database without going through a formal process to make

Post by unknown
The decision to go with a tool like PD is pretty easy
when you consider the cost of poor data design.
Remember that you can export metadata from the models

in a number of formats, like HTML, XMI, RTF/DOC, etc. You

Post by unknown
can also just use the free (as in free beer) PD Viewer
to let an unlimited audience view the model information
, in its entirety, if desired. Oh, and XMI can be used

Post by unknown
If you only use the PDM to RE the DDL, then you are
missing out on so much more of the tool. Capturing
business requirements, data analysis, object modeling,
process modeling, etc are all strengths in PD. Mike

Shao Chan

2007-02-27 09:28:13 UTC

Permalink

Hi Matt,

Thanks very much for that. The xdb file option looks very good although I
guess a fair amount of changes have to go in as a lot of changes were made
to the Progress database from v9 > v10.

My main concern is that the more I use Power Designer, the more others will
need to understand it as well to pick up or do work. There are features
within the Progress database that I must cater for that make high levels of
customisation necessary. It's great that the tool has such capability.

Cheers,

Shao

Hi Shao,
I am going to try to answer your questions without providing opinion for
your PDes specific environment.
1. Naming Conventions - you should look this up in the help. Basically as
you type a new word, the abbreviation will appear in the code. You can do
this either in-line or batch. In-line is described in the help under
Naming Conventions and batch you can use the VBScript in the VBScript
directory. This type of naming convention could include both
abbreviations/word substitution and/or pre/post fix. An example of this is
on the PDes Virtual User Group on the ISUG site. Look for the Roadshow
powerpoint and solution files.
2. Mutli-layer development - PDes supports multiple abstractions of the
same data in order to migrate changes using the Tools -> Generation
option. Becuase if you applied the Naming Standards in PDes the Name would
not change, just the Code in each model (Progress & ASA). Remember the
'Name' is the business name and it is normally consistent across the
board, and the 'Code' is what will be used when the schema is actually
generated.
3.Process of updates- You may be having an issue with the diffs if you are
using the Tools -> Merge. This would be the expected behavior. To get the
behavior you want which is what I recommend, I would use Database ->
Reverse Engineer Database. This will bring changes from production
directly into your model and would change things vs add/delete. Don't
worry this is not an unattended process. Once you choose to do this, prior
to any change, you will recieve the Merge Dialog box to ensure only those
items from production are migrated into the current model state. Once that
is done, I would then go to Tools -> Generate Physical Database, to update
the ASA database with the change.
Progress Support -> For Progress support you might want to consider
building a new xdb like I did for RedBrick. An xdb is the external
definition file that controls how PowerDesigner generates and reverse
engineers any relational database. You would start by basing it on the
ODBC xdb file. Then manipulate the datatype mappings, additional structure
and any of the generation parameters that are needed for that database.
Better yet, start with the one I attached that was from Progress v8 and
change it. I found this out on the SY code exchange.
Oracle Support -> PowerDesigner's primary data modeling customer base uses
Oracle as their primary & prefered RDBMS.
HTH,
-Matt Creason

Post by Shao Chan
Hi Paul,
I never said that any of iAnywhere's technologies were not supported by the
tool - please reread my thread.
Okay, scenario.
1)
http://www.psdn.com/library/kbcategory.jspa?categoryID=194
It is not currently a directly supported database of Power Designer and
therefore, any engineering to generate SQL code must default to selecting an
ODBC 3.0 compliant database. The issues with long binary etc, depends on
http://developer.mimer.se/validator/index.htm
to determine their syntax but I understand that some syntax is not (or was
not given exact syntax in how it should be implemented).
Either way, whoever's fault it is, this means manual modification of the DDL
after it has been generated.
When modelling the database through PD, additional references, e.g. to
storage areas of whereabouts the table will sit need to be translated into
the terminology of the database. Again, the Progress RDBMS is not supported
by PD and therefore a fair amount of knowledge is required in PD to get it
to generate additional syntax (if at all possible).
2)
The above database is a backend database, whereas the mobile database is an
extension of one of the backend database modules. The backend database uses
procedures to limit names of tables/indexes to ensure compatibility with
Oracle. Also all tables created in the backend for the mobile project are
prefixed with 'mb' for mobile whereas there is no requirement for the mobile
SQL Anywhere ASA database.
Now, first of all the reason for the limit on table/indexes (each 14
characters) is because Oracle indexes have to be unique on the same database
schema. Therefore, within our Progress database working procedures (to
ensure our application can be run on an Oracle database), there is a limit,
so that when we convert the database, each index is held
<table>##<index>.
manufacturerRange
would become
mbManuRange
Those developing on the iAnywhere databases should not suffer the shortening
of the table such that it is more obscure. Therefore when generating the
schema for the iAnywhere databases, the full name is used, but for the
backend databases, the mb name is used.
Given that limits are imposed because of technology compatibilities there is
1) Change syntax generated because of non-support of database by PD.
2) Change syntax generated because of table naming differences in each tier.
There is also something else I do not know how to do. The backend system is
the point of entry for database changes as this is the core system. The
Progress database provides its own tools for performing a diffs. We could
not use PD anyway because as far as I can tell, it can't tell the difference
between when a column is altered on the backend database (i.e. if I rename a
field). The field is dropped and a new one is put in its place than a
rename of the field.
Anyway, there are also a few other issues, but given the above, how would
you use PD? As far as I can tell, logically you would use PD at the backend
a) support all the proprietory features of the Progress RDBMS when
generating the DDL etc.
b) change the names of tables etc depending on when the syntax is exported
for the mobile database.
Cheers,
Shao

Post by Shao Chan
Hi Pascale,
Thanks for the reply. No, we use the diffing tool as well. This is also
great. We also after Reverse Engineering use the tool to print out the
diagrams as they way it shows a gridline of how tables will be positioned
when printed is great.
I have always maintained that PD is the best tool around. The reason I
mentioned other tools was simply so that the Sybase Team could appreciate
a commercial dilemna if either their tool was no longer supported or if
it happened not to be the best tool around. It would not look good for
Sybase to use another database vendor's tool possibly.
Tools such as PD require training to make use of it to the tools best
capability. As your group grows more people need to understand and use
the tool. If developing multiple tier database systems, some of which
are not supported by PD and possibly some that are not SQL compliant,
there can be issues in using the tool once you move to the physical
generation of the schema. iAnywhere technologies involves
synchronising
databases on 2-3 different layers. There are some database changes and
naming conventions that might be needed at each layer and PD is not
always the best option forward.
Some people confuse the use of a tool such as PD with using a formal
process. It is possible to do one without the other.
You have a nice day too! :0)
Cheers,
Shao

"Mike Nicewarner" <"mike[at]datamodel[dot]org"> wrote in

Post by unknown
Well, I've worked at a number of very large companies
that have completely embraced model driven design. We
would never allow anyone to just make changes to the
database without going through a formal process to make

Post by unknown
The decision to go with a tool like PD is pretty easy
when you consider the cost of poor data design.
Remember that you can export metadata from the models

in a number of formats, like HTML, XMI, RTF/DOC, etc. You

Post by unknown
can also just use the free (as in free beer) PD Viewer
to let an unlimited audience view the model information
, in its entirety, if desired. Oh, and XMI can be used

Post by unknown
If you only use the PDM to RE the DDL, then you are
missing out on so much more of the tool. Capturing
business requirements, data analysis, object modeling,
process modeling, etc are all strengths in PD. Mike

Nicewarner [TeamSybase]
I know that PD can do a lot even more so in the latest
version. I have never denied that. Neither am I saying
that the best way forward to architect a system is to do
it without the aid of a tool. Neither am I saying that a
formal process should not be used.
I am saying that the formal process does not need to
involve PD or any other tool for that matter. I am
saying that real world realities kick in when considering
the use of a tool and the tool should be used to get the
maximum gain with the minimum amount of effort. These
areas are when starting a new project and reverse
engineering of products to get ERDs for customers to see
and to perform diffs. At least this is the case for us at present.
It's easy for Sybase people to say otherwise. The tool is
theirs and the only tool used in office immediately
allowing disregard to other tools. It happens to be the
best tool on the market. There is no issue with cost.
The majority of databases which Sybase people work on will
involve Sybase databases. All the databases that Sybase
people work on will probably be supported by the tool.
They have a direct order from Sybase to embrace and
encourage the use of their own products. The arguments
are weighted differently for people at Sybase.
I am not arguing technical merit for use of PD or ideal
ways of working. PD is a fine tool, but when balanced
with everything else, its not all roses as it is for
Sybase people.
Cheers,
Shao