- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
One bad hack to fix another!
I approve.
Admin
I kind of think you're setting yourself up for failure. Systems that try to be everything to everyone more often than not end up as fodder for this site.
That said, I take it you're looking for database design suggestions? Well, here goes:
You clearly need to separate information about the objects from information about the relationships among the objects. If you have just a few, similar objects, I would go with 2 tables, an object table (each row is an object) and a relationship table (each row is a binding from one object to another). Scale this up to many object tables / many relationship tables as required by the amount of data you anticipate your system being required to hold.
Admin
Design dev, and test time allowed is always an issue. I have a similar table design (id, text field for storing compressed, custom-serialised object), but it's a case of what works in the real world - low-spec laptops running outdoors, communicating with each other over a busy and unreliable wireless network. Machines need to send high volumes of messages between each other, allowing recovery and catch up if the network is down, so messages are stored in this type of design. The rest of the database has usual relational design, but if you were to query the raw data for thousands of objects, of different types - so a generic query wouldn't work - and create these objects to send over an unreliable network, it would kill the performance on the low-spec machines and make the app unusable.
SO: What's wrong with having a message store, where, on receipt of a request for messages, e.g. "since 12345", they can be just retrieved and sent as-is to the other machine?
Oh, and get it working by tomorrow.
Admin
DB2 9 lets you embed XQuery, a W3C standard for querying XML, in its SQL statements to query both traditional relational tables and inside the new XML column type. It's a very nice solution in situation where a database has to co-exist with lots of xml files -- pretty much every enterprise -- because you can stick the data in the database without shredding it. Shredding is a huge pain because you have to update and test the shredding script every time the schema changes.
Microsoft SQL Server is also going down that route, and it looks as though there will be a way of embedding XQuery in SQL in the next ISO SQL standard.
Admin
On the a>b>c... thing, here's an idea:
Customers table
Types table
Types_Relations table that includes the ID field for the customer, a SeniorTypeID field and a JuniorTypeID field. This is your rule-set for what types can relate to what other types for what customers.
Types_Types join table, with RelationID in it.
Highly normalized, and allows customer-specific rules and integrity.
Also, I suggest posting technical questions like this on pages like TechRepublic, where that's the purpose of the site. Easier to track your answers and such.
Admin
Admin
Admin
In a lot of shops, the DBA/DA is in a seperate group from the application developers, so getting database changes can require running a gauntlet. Rather than fight that battle, it's easier to just stick the data in a string or blob that you control. (That was the reasoning that the Sitara team at Enron used to stick data inside CLOBs. One of the system architects later admitted that they might have made a mistake. They had 2 (two!) databases with extracted data for outside applications to use to get reports, billing data, contact info, whatnot out of.
Admin
We can do something like this, using a modified Entity-Attribute-Value schema. We have a table that lists all of the possible attributes with names, descriptions, and data types. We also have an Entity table which corresponds roughly to an object of a given type. (There are also some tables that specify what attributes a given entity might have). Attribute values are stored in a table whose primary key is (entity id, attribute id).
Admin
Ahem! Would it make you feel better if it was signed off as "Many thanks in advance, Mr. Local Name"?
Admin
I'm one of those who don't like relational data, and its specifically because I hate all the database
software I've ever had to use. My least favorite stuff right now is the entire Microsoft tool chain from
dot net to sql server 2005. Everytime I invest effort into programming any significant project, a Microsoft
upgrade will come along and basically trash what I've done. The linux world is even worse, its favorite
database is mysql and that damn thing isn't even ACID ready. Then theres perl, with its proposed upgrade
path to 6 called the "apocalypse".
The only sturdy programming environment I know of seems to be regular old C, and I'm sure not going
to be very productive there on a day to day basis.
Admin
The only "fundamental design reason" I could think of for doing something like that would be to make it impossible for anyone to access the data using competing software, and I doubt they'd do that... oh wait...
Admin
Are you also applying for a database WTF?
l.
Admin
Data is duplicated in many real world situations. In many companies, data from operational systems (order processing, inventory control, etc.) is copied into other tables on a nightly/weekly basis. These other tables are then used by Crystal Reports to generate reports. They do this so that the operational systems do not slow down when users run reports. Along the way, info may be reformatted, certain business rules may be applied, and data from different tables might be combined into single tables to reduce the amount of data manipulation by the Crystal Reports server.
Ideally, of course, all the info should be in a single place. However, in order for such a set-up to provide acceptable performance to all users, one needs to get very expensive hardware, OS from the likes of Sun (or IBM) and a big, fat multi-CPU licence from Oracle. Such a server will have to have the horsepower to handle very high loads during normal working hours and at the end of the month when many reports have to run - and then see minimal load at night. Hardly optimal.
Admin
WebLogic Integration does this for it's process database. In addition to the problem of not being able to use the data outside of the app server, it causes upgrade problems. If you deploy a modified version of a process, sleeping (serialized) instances cannot be deserialized because the object ID's of the classes don't match. Genius. (WTF, BEA?)
Admin
Admin
Depending on the general conditions, you might even consider executing an "ALTER TABLE ADD (...)" in run-time, whenever necessary.
Of course this requires a level of control that some DBAs simply will not grant you.
Admin
Yeah get rid of that stuff based on relational (set) theory and grounded in maths. Maths is for intellectual weakling who need something robust underpinning their DBMS, not that SQL = Relational anyhow. Where is the mathematical theory underpinning the OO databases?
Admin
Hey Tom,
The poor guy is just trying to get around the awful impedence mismatch of RDBMS's and programming languages. When will Oracle come up with something better. And don't give me those ridiculous "Object Extensions". Steaming heap. Embedded sql (JDBC,ProC, whatever) is the worst hack that has happened to the industry in the past 25 years. Get off your high horse!!
The real WTF is why hasn't this technology advanced??
Admin
Is it so difficult to join??????????? In case, let do that to a DB developer while you have fun with your Java, .net or whatever ;-))
And you get only the data that you want, no "useless" data...!!!
Sigh... :-(
Admin
Aaahhh, better and better, concurrency-wise almost perfect!....WTF....
captcha: lunch time
Admin
Normaly not a big deal, since people are not likely to change their datamodel that often. Probably the biggest problem is that packages referencing that table are invalidated.
Admin
Alter table (in a controlled project) OK, runtime NOT OK. It means that a lot of SQL in the packages has to be built dinamically... Another killer for the db.... And all this for what? The users will extend and customize 20 times the LOVs, then, after one year, they will prefer to change the tool. And the db is still there waiting for the next miracle-interface-language-paradigma.
captcha: create materialized view as select * from tom_kyte;
Admin
Ever wondering why Cognos is running so slow?
Take a look at the content store, a perfect example of the database Tom described. XML stored as blobs, clobs everywhere.
No wonder...
Admin
Wow! Well, I had to "convert" 2D Sprits for a game once, and quickly found out the storage format was x86 Assembler (code+data segment) so I just read the code and wrote some of my own to decompile the data segement into a pcx file.
But imagine conveting such a mess to a relational database. Well, problably just instance the objects using a jvm, and use some orm tool on the resulting class hirachy... an entrprise-scale operation, no doubt. probably works on the first go, being enterprise and all
;-)
Admin
One comment - In sql-server at least, selects can often be faster on normalized tables, as the data-pages needed are more likely to be found in RAM, which is many times faster than if it needs to hit the disks.
Admin
Funny, in 2006 this was called a WTF, in 2014 it's called "NoSQL" and very hip!