I don't want to try and tell you your business, but I had a few thoughts on your mail:
On Mon, 17 Nov 2014 09:18:43 -0500 Eric <e...@esjworks.com> wrote: > > On 11/16/2014 5:16 PM, Jaroslaw Staniek wrote: > > 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 -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted