mongodb and base

users
#1

I've googled a bit and did not find anything. Has anyone coupled mongodb and base together yet?

#2

Just curious, how would you combine relational databases with the
document-oriented ones (such as mongodb)?
Do you have use cases?

#3

Hi :slight_smile:
If you are just looking around for a hefty back-end then Postgresql is
likely to be far heftier than you really need. Similarly MySql/MariaDb are
also strong and well able to cope with fairly vast databases. Postgresql
connects to Base more easily.

If you already have an existing MongoDb database and are looking for a
front-end then it's a different story.
Regards from
Tom :slight_smile:

#4

I've googled a bit and did not find anything. Has anyone coupled mongodb and
base together yet?

Just curious, how would you combine relational databases with the
document-oriented ones (such as mongodb)?

I'd limit mongo to a subset of relational db. think of mongo as the black knight from Holy Grail.

Do you have use cases?

I'm preping to talk to a real estate title authority. they have 60+years of title info in the area and it is all held in informix. they generate reports on the fly (hence base) and would like to be able to add information on properties incrementally without always rewriting the schema and go through the database conversion.

Yes, there may some legal reasons why they can't do this but htat is why er are talking.

personally, I am an order of magnitude more effective with mongo than any sql database. mongo maps better to my mind than sql. I'd like a base connection so I can be more effective in my ad-hoc db tools

#5

Hi :slight_smile:
If you are just looking around for a hefty back-end then Postgresql is likely to be far heftier than you really need. Similarly MySql/MariaDb are also strong and well able to cope with fairly vast databases. Postgresql connects to Base more easily.

good advice. I'll try it for one appl I may have to deal with

If you already have an existing MongoDb database and are looking for a front-end then it's a different story.

not yet, I just detest sql and am campaigning to relegate it to COBOL status. (something you never admit to knowing or using :slight_smile:

#6

[snip]

>
not yet, I just detest sql and am campaigning to relegate it to
COBOL status. (something you never admit to knowing or using :slight_smile:

Good luck with that. Probably has less chance of success than my
Quixotic campaigns to get the U.S. to switch to the metric system,
to get Michiganians to stop referring to themselves as
"Michiganders," to get businesses to stop appending those inane
confidentiality/proprietary warnings to emailo and to make the display
of "Baby On Board" signs an offence punishable by time in the
stocks :).

As an aside: I think SQL rocks.

Regards,
Jim

#7

Nice list of things to work on :-))
Wile in the metric system, you might add paper sizes (A4, A3, etc.) and the perforation of paper..

I used to work for Bell Labs, and they had as standard (!) perforation the US 3 + the US 4 holes, and we just added Europe's 4 holes, so in total there were 11 holes...

#8

hole-y cow!

#9

Was there any paper left? :wink:

#10

I don't want to try and tell you your business, but I had a few
thoughts on your mail:

> Do you have use cases?
I'm preping to talk to a real estate title authority. they have
60+years of title info in the area and it is all held in informix.

That's a lot of data. And Informix is a real workhorse of a database.
Arbitrarily shifting to MongoDB and Base just doesn't sound like a well
though out decision...

Base doesn't strike me as a rock solid, "serious" solution, but that
might be just my perception. However, there are a few more pointers in
your mail that suggest the decision may be less than considered:

they generate reports on the fly (hence base) and would like to be

What exactly do you mean by this? That they regularly want custom
designed reports? Sounds odd. Surely they must have some idea of what
they want to get out of the system on a regular basis? Otherwise it
implies that they don't really know what they want the system for. And
that right there would be a fundamental problem, one that no amount of
engineering will solve.

able to add information on properties incrementally without always
rewriting the schema and go through the database conversion.

A common request, but almost always a bad idea. By "adding information"
you must mean adding fields to the database, which should always be a
carefully considered decision, not an "as the mood strikes" decision.

Assuming that such fields are purely additional data, and in no way
form part of any relationships, then sure, they can be added quite
easily, but the question is always who is going to go through all the
current entries in the database filling in that new field? One can make
the new fields nullable, and just let all old data have nulls for those
new fields, but that just leaves a mess of incomplete data in the
database. If they've been collecting data for the past 60+ years, they
must have a pretty good idea of what data they need. Real estate data
can't change that often.

Yes, there may some legal reasons why they can't do this but htat is
why er are talking.

Legal reasons? I can't think of any. This is their data, they can do
what they like with it, I should think. But I'm a technical guy, not a
legal guy, so I really have little idea. All I *can* tell you is that
from a technical standpoint this sounds like a nightmare waiting to
bite you in the posterior later. And the fact that you think there may
be legal issues may indicate a misunderstanding about what it is the
client is trying to do.

personally, I am an order of magnitude more effective with mongo than
any sql database. mongo maps better to my mind than sql. I'd like a
base connection so I can be more effective in my ad-hoc db tools

At a fundamental level, it sounds like the problem is with the concept,
not the implementation. I'd go back to the drawing board on this one.
Rethink what your client wants to do, and from there use proper tools
to implement it. Much as I am a fan of LO, I just can't recommend Base
as a tool for serious work in the order of 60+ years of data in an
Informix database.

But then again, you know what the client wants, I don't. And as you're
the one who has to do the work, you will need to decide how closely you
want to stick with what you're familiar with. And one assumes you're
the guy who has to live with the decisions. So if you want MongoDB and
Base, I'm sure someone will be able to point you in the right
direction. Unfortunately I can't, as I have no experience with MongoDB.

I just thought I'd point out what seems like a mess. You might well
have thought it through thoroughly, and this advice may be unwarranted
and unwanted, and if so I apologise, but I felt it better to offer
caution than to let you step blindly into harm's way.

It's entirely your call of course, but, given that I've done these
sorts of systems for a living for quite a few years, your description
raised warnings when parsed through my experience filter, and I felt I
should tell you about it.

Paul

#11

I read this e-mail with interest. Paul has raised some very serious points that need consideration. Unless the clients have fully defined their requirements, including any special reporting needs the implementation of this system with any data base software will be problematic. Good data base design requires a properly thought out and detailed requirements documentation. While regarding software as engineering may not be popular, the general attitude of just lets code it on the fly leads to enormous problems which can be much more expensive to fix than spending time on getting a decent requirements document, software design document, test plan and acceptance documentation,
plans for quality assurance and management and description of the operational use of the software. These items are all essential in the successful implementation of a project involving large amounts of data and a number of users.

Over the years I have been involves in the design and implementation of a number of data base systems involving large amounts of data ( many millions of records) and many users (in excess of 100). Without the steps outlined above such systems are extremely unlikely to be successfully developed.

By the way if your clients do require lots of special ad hoc reports SQL provides a convenient way of developing them.

Regards

Peter Goggin