| |
 |
|
| Computers Forum Index » Computer - Databases - Pick » We use Pick for library management... |
|
Page 1 of 1 |
|
| Author |
Message |
| Gee... |
 Posted: Tue Sep 29, 2009 12:24 am |
|
|
|
Guest
|
I have been writing assembler and C++ for PIC ( yup without the K)
microprocessors for some time now. As a group we needed to find a way
of library management, and attempted it with a hosted SQL based
library management system.
Why ? 5 software engineers in the group are familiar with SQL as a
standard. We found that the constraints placed on us by SQL were not
appropriate to our needs. simply by our data mapping requirements.. So
I modelled a simple MV solution - which we all like, understand and
are planning to deploy. Indeed we have adopted the simple hashing
algorithym as a group standard for accessing data in the EEPROM
hardware we use to support our applications.
Why this short epistle ? - Generally MV is associated with complex,
and flexible business solutions, and I thought comp.databases.pick
might like to know that it can also be used for helping to manage low
level engineering problems.
Trust you are all sparky
Godric
PS: We haven't decided which vendor to use - there are only 5 of us !! |
|
|
| Back to top |
|
|
|
| dawn... |
| Posted: Wed Sep 30, 2009 1:38 am |
|
|
|
Guest
|
On Sep 28, 7:24 pm, Gee <g4nl... at (no spam) googlemail.com> wrote:
Quote: I have been writing assembler and C++ for PIC ( yup without the K)
microprocessors for some time now. As a group we needed to find a way
of library management, and attempted it with a hosted SQL based
library management system.
Just FYI. There once was a Prime Information / Universe library
information system named Dynix that we had running on a college campus
in the early 90's. I'm not sure what happened to them (shouldn't be
too hard to research).
Quote: Why ? 5 software engineers in the group are familiar with SQL as a
standard. We found that the constraints placed on us by SQL were not
appropriate to our needs. simply by our data mapping requirements.. So
I modelled a simple MV solution - which we all like, understand and
are planning to deploy. Indeed we have adopted the simple hashing
algorithym as a group standard for accessing data in the EEPROM
hardware we use to support our applications.
Why this short epistle ? - Generally MV is associated with complex,
and flexible business solutions, and I thought comp.databases.pick
might like to know that it can also be used for helping to manage low
level engineering problems.
Trust you are all sparky
Godric
PS: We haven't decided which vendor to use - there are only 5 of us !!
I suggest either Cache' (so that you have whatever future connectivity
you might need, such as excellent MV-enhanced SQL support, as well as
an AJAX framework, etc -- this is what we are using for writing new
software), QM (don't think you should go with this because of the open
source -- that seems to be one of the more complicated aspects of the
tool and you are unlikely to be able to treat it like open source
software for the long haul), or U2 (largest market share in the MV
space by far).
Have fun. --dawn |
|
|
| Back to top |
|
|
|
| eppick77... |
| Posted: Wed Sep 30, 2009 12:27 pm |
|
|
|
Guest
|
On Sep 29, 9:38 pm, dawn <dawnwolth... at (no spam) gmail.com> wrote:
Quote: On Sep 28, 7:24 pm, Gee <g4nl... at (no spam) googlemail.com> wrote:
I have been writing assembler and C++ for PIC ( yup without the K)
microprocessors for some time now. As a group we needed to find a way
of library management, and attempted it with a hosted SQL based
library management system.
Just FYI. There once was a Prime Information / Universe library
information system named Dynix that we had running on a college campus
in the early 90's. I'm not sure what happened to them (shouldn't be
too hard to research).
Why ? 5 software engineers in the group are familiar with SQL as a
standard. We found that the constraints placed on us by SQL were not
appropriate to our needs. simply by our data mapping requirements.. So
I modelled a simple MV solution - which we all like, understand and
are planning to deploy. Indeed we have adopted the simple hashing
algorithym as a group standard for accessing data in the EEPROM
hardware we use to support our applications.
Why this short epistle ? - Generally MV is associated with complex,
and flexible business solutions, and I thought comp.databases.pick
might like to know that it can also be used for helping to manage low
level engineering problems.
Trust you are all sparky
Godric
PS: We haven't decided which vendor to use - there are only 5 of us !!
I suggest either Cache' (so that you have whatever future connectivity
you might need, such as excellent MV-enhanced SQL support, as well as
an AJAX framework, etc -- this is what we are using for writing new
software), QM (don't think you should go with this because of the open
source -- that seems to be one of the more complicated aspects of the
tool and you are unlikely to be able to treat it like open source
software for the long haul), or U2 (largest market share in the MV
space by far).
Have fun. --dawn
Dawn,
I am working with the commercial version of QM and it is quite good.
I would strongly suggest the commercial version of QM. I would
suggest NOT using the gpl version.
Eugene |
|
|
| Back to top |
|
|
|
| Martin Phillips... |
| Posted: Wed Sep 30, 2009 1:00 pm |
|
|
|
Guest
|
On 30 Sep, 02:38, dawn <dawnwolth... at (no spam) gmail.com> wrote:
Quote: ...QM (don't think you should go with this because of the open
source -- that seems to be one of the more complicated aspects of the
tool and you are unlikely to be able to treat it like open source
software for the long haul)
I don't think I have ever heard an argument for NOT using a product
because it has an open source version.
As has been discussed at length both here and on the OpenQM Google
group, the open source version of QM is aimed at developers who want
to play with a "sandbox" in which they can try ideas that they may
wish to contribute to the mainstream source. It is now some way out of
sync with the commercial product but still meets the role for which it
was released. There may be a new release under different licensing
terms in the future.
The commercial product, on the other hand, is a fully supported,
highly functional multivalue database with a growing user base. I
replied off-list to Godric a few days back to say that we had done
private ports to other architectures for specific users. The PIC
sounds quite fun if there is a business case.
Martin Phillips, Ladybridge Systems. |
|
|
| Back to top |
|
|
|
| Adt... |
| Posted: Thu Oct 01, 2009 7:43 am |
|
|
|
Guest
|
On Oct 1, 2:29 am, dawn <dawnwolth... at (no spam) gmail.com> wrote:
Quote: Having worked with library software a bit, I would suggest it depends
on the library and various requirements (of course) which platform to
choose. There are pros and cons to each of the options I listed
(Cache', U2 and QM), as well as others, such as Revelation and jBASE,
each of which also has its charm. cheers! --dawn
And of course there's also Reality, the original Pick/MV product going
back
to 1973, and still being used for complex failsafe applications with
high user
counts now running on Sun, AIX, Windows and Linux platforms... As for
Library systems I know we had many sites, like the national library of
Wales
and British museum at one time - as mentioned above, Pick/MV is very
efficient
for such tasks, scaling from one user and small amounts of data to
thousands
and hundreds of GB's of data... not to mention keeping up with
interfaces like
Web, ODBC/JDBC/XML/Web Services/ActiveX/TCP Sockets/Encryption
Disaster Recovery and MV compatibility... well it does in Reality...
But, working with Pick and Reality for some 30 years I would say
that...
.... Alan Taylor - NIS Reality www.northgate-is.com/reality ; - ) |
|
|
| Back to top |
|
|
|
| Kevin Powick... |
| Posted: Thu Oct 01, 2009 6:26 pm |
|
|
|
Guest
|
On Oct 1, 2:08 pm, Tony Gravagno
<address.is.in.po... at (no spam) removethis.com.invalid> wrote
Quote:
GPL, and thus OpenQM, licensing do allow a company to run their
commercial business on the FOSS.
Err. That's just plain wrong.
There are no restrictions in either the general GPL or the GLP version
of OpenQM that prevent you from being able to use OpenQM in a
commercial environment. However, as you pointed out, there are many
other reasons why you would be better off running the commercial
version of OpenQM.
--
Kevin Powick |
|
|
| Back to top |
|
|
|
| Tony Gravagno... |
| Posted: Thu Oct 01, 2009 10:08 pm |
|
|
|
Guest
|
dawn wrote:
Quote: I do not know how many people have
production software running on the open source version, but I "feel"
there is more of a bait-and-switch than one might "feel" from MySQL,
for example.
So, I would suggest thinking of the open source version
of OpenQM to be somewhat like a developer copy of another database and
if you really have production code, I'm guessing that most people pay
for the commercial version.
GPL, and thus OpenQM, licensing do allow a company to run their
commercial business on the FOSS. Yes, a real business should prefer
to run their business on a commercial license, not for legal reasons
but because:
1) As discussed with Eugene the FOSS OpenQM is far behind the QM
commercial product.
2) OpenQM FOSS is unsupported except for what you can find in the
public developer forum. "Unsupported" as in: you can get free help to
understand how to use the software from the developer forum and even
the commercial QM forum, but you won't get help direct from Ladybridge
and you won't get any product changes if the FOSS doesn't work
properly.
However, there are additional subtleties of the OpenQM license which
make it's usage in an end-user environment ...precarious. For
example, if you contract with external, non-employee application
developers, then your business software must be GPL'd according to the
OpenQM FAQ page. And there are conflicts of opinion about whether a
change to your business software implies a change to the DBMS, thus
again potentially mandating your application to be GPL'd - this is
related to concepts of linking or keeping your code at "arm's length"
(GPL FAQ term) from the underlying GPL package. Since I don't "feel",
as you say, these concerns when I work with MySQL, then to some extent
I'd agree with your impression.
My advice: don't bother with FOSS OpenQM unless you are interested in
the underlying mechanics of how the DBMS works. It's not for
application developers - at least not yet, maybe until the platform
can gain some popularity as an alternative to LAMP and the license is
modified to be more in line with LAMP user expectations.
OpenQM isn't a vehicle for free=beer="run your business on no licenses
and laugh at the idiots who spend their money on DBMS software because
they're too stupid to get it all for free". If you are an end-user,
buy a commercial license - full stop. If you are an application
developer, contact Ladybridge to see what kind of commercial or
developer licensing is available. Either way, take the word Open off
the table. You'll note in my original note in this thread I said "QM"
and didn't use the word "open" at all. I dare say we should never
really see discussions about using "OpenQM" in this forum.
T
Now tweeting occasional tech notes as TonyGravagno.
(I have been assimilated ... resistance was futile) |
|
|
| Back to top |
|
|
|
| Kevin Powick... |
| Posted: Fri Oct 02, 2009 9:32 pm |
|
|
|
Guest
|
On Oct 2, 1:50 pm, Tony Gravagno
<address.is.in.po... at (no spam) removethis.com.invalid> wrote:
Quote:
So what's wrong with the quote below? I'm guessing you mis-read
I was wondering why nobody else picked-up on your error.
--
Kevin Powick |
|
|
| Back to top |
|
|
|
| Tony Gravagno... |
| Posted: Fri Oct 02, 2009 9:50 pm |
|
|
|
Guest
|
So what's wrong with the quote below? I'm guessing you mis-read that
and thought I said "don't" instead of "do"?
T
Kevin Powick wrote:
Quote: On Oct 1, 2:08 pm, Tony Gravagno wrote
GPL, and thus OpenQM, licensing do allow a company to run their
commercial business on the FOSS.
Err. That's just plain wrong.
There are no restrictions in either the general GPL or the GLP version
of OpenQM that prevent you from being able to use OpenQM in a
commercial environment. However, as you pointed out, there are many
other reasons why you would be better off running the commercial
version of OpenQM. |
|
|
| Back to top |
|
|
|
|
|
All times are GMT
The time now is Sun Nov 22, 2009 7:41 am
|
|