I'm interested in hearing from people who are running (or have run)
transaction processing systems on both an MV system and SQL Server.

Question: What are the differences in cost of ownership that you see
between these two environments?

I'm interested in your intuition as to whether the total cost of
ownership for each environment is roughly the same or whether one is
less expensive than the other. I'm also interested in any more
specific information or impressions you might have.

Some categories might be:
1) Ease in learning & training
2) Actual hard costs in the budget for the software
3) How much hardware is required for each: cpu, memory, disk
4) User access (e.g. 24/7)
5) Reliability, risk of downtime, risk of data loss
6) Number or fraction of professionals required to support a production
environment in each (and/or lists of what tasks are required on an
on-going or periodic basis)
7) Cost of optional and 3rd party add-ins
8) End-User Satisfaction
9) IT User Satisfaction
10) Ease, speed, & quality of new software development & maintenance of
existing in-house software
11) Vendor support
12) Ease of getting the data back out, is there a need to make data
marts for reporting more often in one environment than the other?
13) Cost of establishing or maintaining security / access
14) Cost of backups
15) Performance
Other categories?

Thanks in advance for any help you can give. --dawn

Dawn,

It would be helpful to know just what you intend to do with the
information in your survey. Knowing that could generate more responses
to your query.

a. What do you consider to be a "good" response. 2? 20? 200?
b. Are you writing an article for a publication? If so, is the pub pro
MV or con MV?
c. --or-- Do you just want to know for yourself?
d. Do you intend to publish the results or just let the responses speak
for themselves?

Some feedback would be appreciated.

Dave Weaver, Weaver Consulting


dawn wrote:

Some companies pay good money to consultants to help them decide their
IT strategy. Not many of those consultants have a lot of knowledge or
experience of Pick/MV but a very sound knowledge of SQL relational
DBMSs - Microsoft's SQL Server along with all the others, and the myriad
applications that can readily be deployed using them. I think it would
be valuable for the companies looking to make a decision, and for the
consultants trying to help them, to have the information Dawn is
looking for. In my recent experience, one of the important factors
influencing the decision making process is the availability or
otherwise of IT professionals with the required skill-set. It never
ceases to amaze me that. I found it very easy to get to grips with Pick
(background: Assembler & COBOL) and am often astounded that some IT
people seem to have difficulty mastering Pick skills. Weren't many Pick
applications built by people with little or no background in IT?
Annoyingly - another is the *perception* that Pick/MV is on the way
out. That can become a self-fulfilling prophecy if it isn't weighed
against more factual considerations. I hope this thread thrives.

Cheers
Mike.

Dave Weaver wrote:
I'm doing a talk at the end of this month at a regional var conference
for a var that has a new SQL Server solution as well as their UniData
solution. As I often do, instead of picking a topic I know well, I
picked a topic I wanted to know better. So, I'm doing some phone calls
now and thought I'd ask this group as well.

No plans for that, but I plan to start a blog this month (to paraphrase
Mark Twain, I think, "anyone with half a mind to write a blog does") so
it is imaginable that something could end up there at some point
(although no such plans)

it's me you're talkin' to, Dave ;-)
It is objective, of course.

These are the types of topics people ask me about, so I thought I
should be prepared. Additionally, I just had a face to face
conversation with a colleague where we walked through cost of ownership
issues of UniData compared to Oracle, both of which he was running in
production environments. He made a good case for Oracle having a
better COA today (compared to previous years) which really surprised
me, so I thought I'd see if I could get a current pulse on MV vs SQL
Server COA.

I'm only intending to use them for my presentation if I find them
useful.

Does that help clarify? Thanks. --dawn

dawn wrote:

Can you actually get true transaction processing from any MV system? -
Not transaction logging, but true, commit/rollback functionality? I
think D3 has Begin/Commit Work, but does it actually function as
advertised? Never heard of anyone using it successfully.

SQL server should be lower. More learning and reference materials
easily available. SQL exposure greater at school. Larger, experienced
workforce.

Licensing for SQL server on par with or lower than most MV
implementations.

Most MV systems should get more bang for buck in hardware, but powerful
systems are so cheap these days that the point is mostly moot.

Most MV systems now ride on a host O/S so uptime is defendant on that.
Many would argue that *nix boxes have better uptime, but I've found MS
systems can be just as solid. Since many *nix systems are thought to
be less expensive than MS, and SQL Server only runs on MS, I suppose
you could say MV on *nix is cheaper, but the cost of the box/OS should
be a relatively small part of the DB budget

Reliability probably similar, but data loss due to user/developer error
probably higher in MV systems.

Modern tools have made SQL server "point and click" simple to
administer. No more staff than an MV environment required - IMO.

Many more available for SQL world, resulting in competition and good
pricing. Fewer options and higher pricing in MV world.

Little to do with the database, but rather the application interfaced
to it.

"Modern", sophisticated IT staff would find SQL server provides greater
standards, tools, resources, and ultimately, satisfaction.

Easier and faster with SQL server if delivering modern, GUI
applications and reporting. Most OEM and 3rd party tools for database
software development are geared towards SQL. Providing similar
end-user applications with a MV back end is more difficult and
time-consuming.

SQL server = Better support @ lower cost.

Shouldn't be, but this approach is probably more common in SQL
environments. MV people seem to like 15 years of history on-line,
regardless of how long it takes to generate their reports.

More facilities and options in SQL server.

Same media available for either, so no real advantage to either.

To vague. Either can be tuned or applications designed to give optimal
performance.


--
Kevin Powick

Kevin Powick wrote:
Of course you can, but what you might consider to be typical ACID
transactions just might be composed of code plus dbms ;-)

I haven't used such a feature in U2 either, but that doesn't mean that
the system under consideration is not a transaction processing system.
We used to write transaction processing systems with indexed-sequential
files, with varying degrees of ACIDity, but all categorized as OLTP.

agree

any guesstimates on number of production-seasoned professionals in
each? You might be surprised how many old Prime Information, Reality,
and PICK professionals aren't in the casket yet. But there are
definitely a lot of IT pros with SQL Server experience in one role or
another.

I don't have any figures for a production SQL Server environment that
would support 500 users, for example -- do you?

Can you scale SQL Server as high as pick? Would you need to do
clustering?

That's good to know. My experience with Windows servers is that even
after many of the initial problems were solved, there was still a lot
of bouncing the server -- almost an alt-ctl-delete mentality. In a
live, yet constantly changing production environment from an
application perspective (software updates), do you get continuous
uptime for more than a week? I've seen months of uptime on *nix and
never more than a week in Windows servers (again, my experience is now
dated).

agreed

ok (meaning that I'll record your intuition on that, reserving
judgment)

ok

Sounds likely

In theory, but in practice, I suspect I can feel the difference. When
developers need to make a call, they often go for something that fits
with their toolset

ok

ok

agreed.

ok

might depend on MV vendor

agreed. There is a reason for that IMO

agreed :-)

agreed

And performance depends on the h/w too, obviously. But I suspect that
this is a problem area for SQL Server, at least in comparison to MV
systems.

Thanks, Kevin. --dawn

We (the developers) used the TRANSACTION... statements on the systems
we developed on UniData for MAFF (now DEFRA) in the UK. I can't swear
they were totally ACID but I never heard anything to suggest they
weren't.

Mike.

dawn wrote:

Then if MV relies more on the application level for ACID TP, it is more
prone to failure due to developer error. SQL-based DBs often have the
transaction processing, constraints, etc to maintain data and
referential integrity built-in at the DB level.

No, but the ratio is probably similar to that of the market penetration
of each type of system.


No, but shouldn't it just be a matter of licenses X users? Besides, are
we talking 500 concurrent users? Is this really the size of the system
or just an arbitrary number?

That many users also suggests a large amount of data. Regardless of
the DBMS, I doubt anyone would, or even could deploy such a solution on
a single box.- I can hear the "32 Pick users on a first generation
i386" tales coming my way.

What do you mean by scale? Number of users, volume of data, both? I
think questions like this are difficult to answer without a "real
world" scenario to work with.

I've had NT4 and W2K boxes in large (50-100+ users) environments
running 24/7 for years without a hiccup -- If you leave them alone.

The boxes that crash are the ones where people are constantly loading
crap on them. Lets face it - A Windows users is typically less
sophisticated/experienced than most *nix users, and since MS server
environments "look" pretty much like desktop ones, I think you get more
inexperienced people screwing-up their systems because they're more apt
to "play" with them.

Also, *nix systems actually DO crash. I've done it more than once.

True.

It's hard to say because it all comes down to what you intend to do
with your database. Is it just for lookups of single records? Is it
for report generation and data mining from millions of records? Is
there a massive amount of daily input/updates from single users or bulk
loading of data? All these are factors and one DBMS may perform better
than the other in a particular situation.

For the record, I've been using MV products from Pick/RD, ADDS, GA,
MicroData, and jBASE since the mid 80's, but have now basically dropped
MV development for RDBMS like MySQL, PostgreSQL, MS SQL Server, and a
few other, lesser-known products.

Why? From a business perspective, it's a much easier "sell" - follow
the path of least resistance.

From a developer perspective, it's easier to give today's users and IT
departments what they want, and it's a lot more fun doing it, because
you don't have to jump through hoops like you do when trying to get
your dev tools to work with the MV data model.

I have a feeling a thread like this could generate endless debate,
which will probably be quite pointless as these things rarely effect
change, but rather generate feelings of validation or objection,
depending on how one's post(s) are received. :-)

Good luck with your report/project.

--
Kevin Powick

[chop]

That many users doesn't always mean there are 500 users doing the
same thing or accessing the same data. Are there companies running on
SQL that have a lot of users? Yes, but they tend to departmentalize
their data and have to perform daily processing tasks to move the data
around. I know, for a fact, that the local Pepsi plant uses Access and
Access macros to manage SQL data for truck routing and orders. I don't
know which data store they're using, but it has to be SQL based. My
wife routes trucks and handles orders there. She said it takes about
1.5 hours to process the daily truck routes and orders using the
macros. The whole order handling process could be streamlined in MV,
while still providing the SQL resources for the truck routing
software. Then again, if a designer only sees 2 colors of paint then
his view of the world is quite bland.

Scale involves all aspects of managing the data and applications that
rely on that data. If you need to scale your business, then everything
that runs it needs to be capable of growing without killing the profit
or the IT staff trying to keep it all up to speed. :P MV and SQL are
quite scalable, but scaling it is totally dependant upon the hardware
and the knowledge of the IT staff managing it all. Most MV platforms
have inherent capabilities to scale by clustering data across
machines. You can do the same with SQL by linking external tables, but
is it as efficient? That's always been a question in the back of my
head. Has anyone done a real performance and scaling comparision
between SQL linked tables and MV remote files?

The biggest problem with Windows stability is the relationship
between the less-than-intelligent file system and its user memory
management. I have drive failures under Windows that are several years
sooner than the same hardware running Linux. The fact that Windows
relies so heavily on disk swap is the main reason why Windows machines
crash more often. All it takes is one bad disk read during a virtual
cache read to kill explorer, or worse. I've seen the registry and
backup register get totally wasted due to one bad sector in a
non-system area. Basically, the O/S is too much of a hog to run
properly on typical PC installs. You need a RAID array just for the
virtual memory, to make sure that Windows doesn't trip over its own
mis-steps. I have a file server running Win2K on a RAID10 Opteron box.
It hasn't skipped a beat in years and I even have BOINC running on it.
On the flip-side, almost all of our desktop PCs have regular problems.
The PC problems are not because of "crap installed". I shoot people
that install stuff without my permission.

The only time I've had problems with Debian is during kernel
recompiles. I've had numerous problems with the RH 9.0 kernel and the
hardware modules running under it. When stable modules are compiled
into the kernel, you get a lot less grief.

That's true.

That's subjective. You're not selling the DB, you're selling the
application. It's a nice benefit to say "yeah, we use SQL" when the IT
staff considers the possibility of mangling your data. :P Joking
aside, there _is_ a lot more stuff (now-a-days) that you can do with
SQL based data stores. However, I still don't see the benefit when it
comes to working for a company that is growing yearly by leaps and
bounds. That's why I have yet to leave MV. Read my interview in DBTA
about All-Spec.

http://www.dbta.com/multivalue/archi...ml#mvcommunity

I may leave MV one day, but at this point the application design and
deployment benefits outweigh the benefits of using an SQL data store
and writing applications externally. That's not to say I'm not using
SQL at all in our business procedures.

Integrating and designing with maintsteam technology is not any more
difficult with MV than it is with non-MV. The size of the brick wall
(from either viewpoint) is totally related to the experience and
knowledge of the design staff. It's also related to the tools made
available, if the staff are not capable of writing the tools
themselves. THAT is the problem currently, but OpenQM is paving the
way for others to see the light. Hopefully, other vendors will see the
light and realize what the MV community really wants and needs.

I was performing live cXML exchanges with Ariba, using D3, back in
2000. If you focus solely on SQL exchanges with MV, then yeah it's a
major PITA. That's due to design differences in the models, not due to
the environment itself. You can still make the same things happen, but
you can't get there if you don't know how to.

The debate will always continue as long as there are developers who
are biased one way or another due to a lack of knowledge. You have to
keep in mind that there are a lot of developers reading this newsgroup
that still haven't learned about SQL and the technology behind it,
much less XML and how web services work. There's 1000 times more
developers that have never heard of "Pick", or have never taken the
time to learn about it when they happen across it in their contracting
gigs. That's why so many MV->SQL conversion go south and end up
killing companies.

Glen
http://mvdevcentral.com
http://picksource.com

--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access

Glen wrote:

Does that pitch still work today? I don't find it that way. People
are a lot more aware of the technology backing their systems. Name
brand recognition in the DB world goes a long way. Unless the
application is unique, only runs on MV, and the prospect can't live
without it, convincing them to go with MV is more difficult.


IIRC, you are developing internal solutions right? Not selling
solutions. Try selling a generic software solution to a mid-sized
company that does not run on a widely recognized database platform.
Good luck.

Nice read, but nothing jumps out as not easily attainable with a SQL
back end. You have access to source code which allows you to maintain
your software. You could have done this with any DB.

The big question. What happens if you leave this company? How easy
will it be to find a suitable replacement? Are any MV developers doing
their clients/employers any favours by exposing them to the risk of
being orphaned?

If I develop/sell a MySQL based application with C#, ASP.Net, PHP, etc.
and allow the customer to have or escrow the source code, they can
easily continue development and find support if I move on.

If it works well for you, then certainly continue. My business
requires applications with all the fancy GUI features and connectivity
options that most people have come to expect. For me, it's easier with
RDBMS, it's more productive and easier to sell.

Oh really? Drop a data-aware grid on your form and connect it to your
MV system with a query to provide a subset of the data you're looking
for. It's about a 2 minute exercise with a RDMS. Not so in MV. Now,
give the user the ability to update that data via the gird. Not so easy
in MV. It takes a lot of custom coding. Maybe with MV.Net and PDP.Net
it's easier for .Net developers. I don't know.

There are simply hundreds of tools and components all designed to work
with the SQL world that make it far easier than MV. The choice,
quality of products, and pricing cannot be beat.

Why would staff write their own tools? That's what tool development
companies do. They spend hundreds of man hours/months/years creating
tools that you can buy for a pittance. What possible economic benefit
would there be to creating your own tools, unless you planned to sell
them?

I often see CPD requests/replies for data connectivity, manipulation,
and output, that people spend way too much time (= $$) on when in the
rest of the world, we buy a component for less than $100 and are off to
the races in a few minutes.

Pick has bred a "do it yourself" mentality that people see as a badge
of honour, when in reality, it's what holds them (and MV in general)
back.

Sheesh. Take an obscure data model (MV) from an even more obscure
company (Ladybug), and open source it. The path to commercial success
for the MV world? - Highly doubtful.

Is it lack or surplus of knowledge that creates bias? It's more than
that. A lot more.

It's not going from MV to SQL that fails. It's trying to rewrite
software in 1 or 2 years that may have 10-20 years of development
behind it. These projects rarely fail due to technology alone.

--
Kevin Powick