My company did a POC a few months ago for a bunch of database vendors, including Oracle. Interestingly enough, just about every one of the vendors we brought in was going down the appliance path - selling a combination hardware/software. This included Oracle - they have something very, very new - we would have been one of the first to use it.
All I can say about Oracle, is that I hated using it. More than likely, though, it was the company’s fault for how it was put together. I forget the names of the programs used before switching to it, but they were much easier to use.
The Oracle screens were so busy and it was just so freaking cumbersome to use as the end user.
This was for a Technical Support database, along with Sales and customer service, so it could also just be how we were using it.
That is not true at all, and frankly makes no sense. I think you got some shitty training.
It does not, and vice versa.
FileMaker is a RAD environment. You can change field names, table names, how tables are related, the behavior of scripts, and the appearance of the user interface while a couple hundred users continue to use the system.
In Oracle (or for that matter MS SQL Server or MySQL or PostGreSQL etc etc) what you’ve got is a very fast engine that scales up almost effortlessly, with no interface to speak of; so any deployment of it is going to have a front end which exists as a separately coded environment whether it be in Brio or Crystal Reports or in php files or in some other front end environment whether open source or proprietary. These may or may not exist only in a centralized location (they may instead be distributed as “reporting applications” to various nodes in the network) and they may or may not communicate with each other (in the simple sense of one php page posting data to the next php page or in more complicated cascades of interdependencies). ALL OF THAT has to be considered before any changes can be made, and the changes synchronized, which is usually a sufficiently messy task as to require testing (sometimes extensive testing with an actual plan of what categories of sample data to throw at it). That makes changes time-consuming and expensive, and that in turn means you need to study in advance exactly how you need it to behave and then you implement that, after which point you mostly have to live with what you opted for.
Working in modeling clay versus carving in basalt.
Different strengths, different weaknesses. You shouldn’t try to run the Social Security Administration of the United States on FileMaker, and you shouldn’t try to run your mid-sized company in Oracle.
I can see value to that in a prototyping environment, but that doesn’t make sense in a production environment.
It sounds like you are talking about a reporting only environment as opposed to an OLTP environment.
Assuming we define a mid-sized company as 50m to 500m in sales (ERP vendors usually put mid-size in this general range), I would say Oracle is an excellent choice (I would choose it over others purely for the way it handles concurrency). At the low end (<50m) the advantages start to disappear.
Are there any OLTP FileMaker systems of decent size in use? I’m not aware of any. How does it handle concurrency?
Standard record locking. You can script the locking of a record, but it also happens automatically when someone clicks into a record and starts editing it.
I’m a professional FileMaker developer (12 years at it) and most of the time when I work I’m working in a production environment. It makes all kinds of sense when the powers that be are still fleshing out how the db should behave and most of the end users get some input into desired db features & behavior. ETA: And no they aren’t “reporting only”. We don’t use the acronym OTLP. It would be like saying “cars that GO somewhere”. They all do.
Locking varies quite a bit in different dbms’s. One of Oracle’s strengths is that readers don’t block writers by default and you get a view of the db at an instant in time.
Meaning the type of lock that prevents others from reading? or the type that prevents others from updating?
Either way, what happens when the person editing the record decides to go to lunch before finishing and someone else is running a process that needs to update that record?
Breathtakingly wrong. Even with Oracle 10 you can use a generic SQL client like Toad using the SQLNET protocol. No web required. What is it about this subject that makes clueless people crawl out of the woodwork to put in their wrong two cents?
I was simply stating what happened at my job. We ran Banner with Oracle with client/server for 6 years. We had 4 production servers and 2 test. Workstations had a network drive mapped to one of the servers. We ran Banner from that drive. Our campus has over 500 staff and faculty workstations using Banner.
After a major Banner/Oracle upgrade all the servers were taken down. We had to modify every workstation so it didn’t create a network drive anymore. Banner is now started using a web browser (usually IE). For reporting, Oracle Database Instant Client has to be installed on the workstation. Instant Client includes SQL *Plus. I use it almost every day for queries. We’ve used this setup for almost five years.
For us, Banner and Oracle are tied at the hip. An upgrade to Oracle usually means a new version of Banner. That’s just how it works.
Okay, first, “network drive” has nothing to do with Oracle, that’s a Microsoft piece of work there. And internet explorer has no relationship to Oracle. Oracle requires no web browser for anything. What you’ve got there is this Banner , which is clearly a piss-poor piece of software written by idiots with some bizarre configuration requirements, and nobody smart enough to understand the difference between a relational database and a jacked-up software package. Just because you access them both by clicking the same mouse and staring at the same monitor doesn’t mean they’re the same things.
Sorry, dude. In a “professional” environment, you are never making changes directly in production. That’s what DEV, TST, and STG are for. I’m assuming you work for very small clients (ie, less than 10 concurrent users). It’s probably a great living for you and you’re absolutely right that you don’t need Oracle for that market. Make it mission critical with millions of records and thousands of users and it’s a different world. Oracle or SQL Server (in a robust cluster) isn’t an option at that point, it’s which one.
When I refer to record locking I mean preventing editing / updating. Anyone can view any data that their privilege set allows them access to regardless of record locking.
Usually they complain to me (FmPro sysadmin) and once I verify that they aren’t at their workstation I [del]nuke them from orbit[/del] have FmServer disconnect them which unlocks the record in question.
You assume wrong. Average load 120 concurrent users, peak load around 450 concurrent users. Cross-platform, over wide area network.
And you make changes directly in PROD, during the work day? All I can tell you is, not on my watch. What’s your rollback plan, if the change goes bad?
Unmake it.
Why do you ask?
Actually I know quite well why you ask. In YOUR environment, making the change (or backing out of it) is most often a huge affair. In mine, it’s not much more complicated than editing the contents of the post I’m writing this very moment.
OK in all fairness, for really MASSIVE structural changes (like splitting Table X into tables X1 and X2, deleting some of the fields from X1 and a good many of the others from X2 and establishing a new one-to-many rel between X1 and X2, and making Table Y, formerly a direct child of X1, into a child of X2, and redoing all the layouts, scripts, value lists and etc, and commuting the data with appropriate modifications and default values) is NOT something I’d do in the live system. I’d do that on a local copy and then shut down the main system, dump sample data from the dev copy on the dev HD, import, and run parsing / splitting scripts to convert, then stick the new version on server. Much as you probably would.
But for simple stuff like adding a new table, adding or changing a relationship, adding 15 new fields, adding 5 new screens, adding a couple of reports and changing validation formulas for acceptable values on 5 existing fields, that’s day to day stuff and it HAS to be done with ZERO downtime and has to be ready before end of day.
The fact that Oracle folks would say “hell NO” to such a request is the very reason Oracle is not the right tool for the kind of environment where everything is still in such flux. Which does describe the vast majority of small to medium sized offices.
I did not know FileMaker was still around , I have not heard anyone mention it for 10 or so years. Does anyone use it outside the Mac world? Everything I hear now is Oracle, SQL Server or MySQL.
Got news for you. It’s not Oracle that makes says “hell no”. Oracle supports those kind of changes just fine - even in PROD. It’s the IT folks, the Audit folks, the Security folks, the Accountant folks, and the Management folks that say no.
Now. If you’re making the kinds of changes you’re talking about in PROD then you’re working in a RAD/SCRUM world and that kind of stuff is acceptable there. You (or more properly your clients) have traded the hassle of actually properly designing the system before deployment for the risk of you making those kinds of changes on the fly. It’s a valid decision as long as it’s made from an educated position.
Don’t mistake the practices of DBAs for Oracle’s abilities. I defy you to find anything that Filemaker can do that Oracle can’t. That’s different than saying that because you do things in your Filemaker database that a trained Oracle DBA would resist that Oracle is incapable of doing it.
Damn. Edit window closed:
What do you mean “unmake it”? You’re talking about changing relationships in production. What happens when someone has edited a few hundred of those records and you try to “unmake” it? They just lose the work?
Of course not. I can change relationships without modifying the tables to which the relationships apply. If It seems reasonable and appropriate, I can modify, move, or reconfigure the data that they’ve entered so as to most appropriately correspond to the original / ‘unmade’ schema after changing the relationship, but I don’t have to. If I do, that’s another script, perhaps 45 minutes’ to an hour’s work on top of the relationship mod itself.
No big deal.
I agree with every word of that.
Agreed there also, but it’s generally going to TAKE YOU LONGER. Because you have to mimic those changes in your front end which is generally a separate environment with a different code set. It’s HARDER for you to do it. Oracle itself though? Yeah, no question about it, it’ll totally do it the moment you ask it to. Drop yonder table, change what that column’s data type is, whatever.
Oracle is seriously powerful and deserves its reputation.
But for a lot of deployments using Oracle is like using a flamethrower when a Bic lighter would have been the more appropriate (and more easily handled) tool.
That really isn’t a limitation of the database engine, it’s really more of a change management process that exists to protect the business from the risk of the application falling apart.
Here’s a real typical example I was working on today: we are going to start tracking the serial number of certain items as they are packed for shipping in the distribution center, which are then transmitted to a separate system where they undergo additional processing. In your environment, wouldn’t you want to test it, train the users, etc.?
The bulk of the work in apps is not installing the changes, it’s carefully designing a good process/system that meets the business needs, building it, validating it really works, training users and managing the implementation, lather, rinse repeat.