Comments on: When should you store serialized objects in the database?

By: Anish Sahare

Anish Sahare — Wed, 07 Dec 2011 12:08:33 +0000

how to save json data into oracle using procdure
and which are the packages and type require to run the procedure

plz send the example to email address

Regard’s
Anish Sahare

By: Edward Wittlinger

Edward Wittlinger — Wed, 09 Feb 2011 14:40:16 +0000

I have a startup that is in the very beginning stages of engineering a website that will process data between user accounts. The database will store user data which in most cases is static data that includes a mug-shot of each user (I’m not that worried about that)!

Where the database get’s complicated is the user accounts each have a full figured avitar that needs to be rendered on the fly with an ongoing second by second manipulation of the data for each account!

And like any good business man, I’m planning for growth. What if the website ends up with 50 million user accounts (I know, I’m dreaming, BUT)… What if?

Trust me, if Facebook had to start over and knew what they know now, do you think they would have used MySQL again?

Based on what I have been reading a lot of you don’t like PostgreSQL, but has anyone looked over the latest version 9.0 or greater with regards to the replication?

streaming replication:
This streaming replication allows one or more databases to be replicated from a master server. It’s an asynchronous transfer but very quick.

In addition to the new streaming replication, Postgres 9.0 also features a hot standby ability. This allows a secondary database to be designated as a hot standby should the primary database fail.

Another big new feature is the addition of an in-place upgrade.

My question is would PostgreSQL be the way to go with it’s ability to handle geometric shapes?

Edward Wittlinger

By: Vinay Binny

Vinay Binny — Mon, 17 Jan 2011 09:02:59 +0000

Another downside to this approach is refactoring. If you refactor a class whose instances are persisted in the database in serialized form, you have to take care of that. Usually by writing a separate program/s that needs to be run out of the application’s deployment environment. Imagine the plight of this refactoring when instances like Hibernate proxies are serialized inadvertently.

The only way to avoid this refactoring nightmare is to store instances(serialized) of native language classes like Java’s String or classes that are part of stable frameworks, value objects are ok, store entity objects at our own risk as they may give you state synchronization problems. Once tool I see that does this is Quartz(or its spring supported bean), which is a scheduling framework written in Java.

Of course, you can probably avoid this if your language gives you a ‘seamless’ way of refactoring/manipulating classes in the serialized data by just replacing the class names which are usually stored as plain strings rather than binary. Still that may not cover all the refactoring cases.

By: Diego

Diego — Sat, 06 Feb 2010 20:20:07 +0000

Great post and discussion. IMO, unless someone is really unconfortable with trying new dbs (which are somewhat not as proven as mysql), they shouldn’t mysql that way. It’s harder to administer than any nosql db, and it’s just not the best tool for storing key/value data.

By: Leo Petr

Leo Petr — Thu, 04 Feb 2010 00:16:12 +0000

Hi, I’m dropping by via the High Scalability blog.

This is a neat technique.

Something similar but much simpler can be done in IBM DB2. DB2 has a built-in, indexable XML column type. There’s native support for XPath and XQuery, so you can store a clob with arbitrary fields serialized as XML and then do SQL queries with XPath to extract arbitrary fields, run aggregation functions on them, etc. Effectively, this lets you do exactly the same thing except without the opaqueness and with potentially higher performance depending on what you want.

This is included in the free edition (ibm.com/db2/express/)

Disclaimer: I work on the DB2 team, the opinions are my own, etc.

By: Baron Schwartz

Baron Schwartz — Wed, 27 Jan 2010 01:50:17 +0000

This is completely OT and not meant to be trolling, but one of the things I’ve always thought Postgres could improve is make their data files less architecture-dependent.

By: Rob Wultsch

Rob Wultsch — Wed, 27 Jan 2010 00:01:18 +0000

Mark:
“All table rows are structured in the same way. There is a fixed-size header (occupying 23 bytes on most machines), followed by an optional null bitmap, an optional object ID field, and the user data. The header is detailed in Table 53-4. The actual user data (columns of the row) begins at the offset indicated by t_hoff, which must always be a multiple of the MAXALIGN distance for the platform. The null bitmap is only present if the HEAP_HASNULL bit is set in t_infomask. If it is present it begins just after the fixed header and occupies enough bytes to have one bit per data column (that is, t_natts bits altogether). In this list of bits, a 1 bit indicates not-null, a 0 bit is a null. When the bitmap is not present, all columns are assumed not-null. The object ID is only present if the HEAP_HASOID bit is set in t_infomask. If present, it appears just before the t_hoff boundary. Any padding needed to make t_hoff a MAXALIGN multiple will appear between the null bitmap and the object ID. (This in turn ensures that the object ID is suitably aligned.) ”
http://www.postgresql.org/docs/8.4/interactive/storage-page-layout.html

By: Brian Cavanagh

Brian Cavanagh — Tue, 26 Jan 2010 15:53:14 +0000

Yeah PostgreSQLmight be a good choice if you can get around the lousy replication support, as it will let you store arrays and another data types natively in the fields, so you don’t have to worry about an inaccessible object model.

By: Mark Callaghan

Mark Callaghan — Mon, 25 Jan 2010 02:52:07 +0000

Josh – what is the cost of a null column in Postgres? Do possibly null columns require a bit in the row header?

By: Josh Berkus

Josh Berkus — Mon, 25 Jan 2010 02:44:59 +0000

I just thought I’d mention where PostgreSQL is for this: It’s less costly to have null columns in PostgreSQL than in InnoDB, so having lots of null columns is not a reason to use E-Blob. Postgres is also very good at storing blobs, and compresses them for offline storage automatically. Also, with GIST, GIN, expression indexes and HStore (and the upcoming HStore-to-JSON) there are indexing options for blobs. So thats two reasons TO use them.

Reasons to use E-Blob are:

a) the data stored varies wildly per entity, over time, or between customer installations;

b) the data in the blob is almost always retrieved, read, and updated all-at-once due to the application design;

c) the data is not going to be used for aggregation, ad-hoc querying, or response-time-sensitive filtering (since cheap indexes are impossible);

d) the data does not need to be constrained or used to enforce a constraint

Reasons not to use it are:

1) the above-mentioned update cost: update an entire 1K blob to change one value;

2) complete inability to enforce meaningful constraints on the data, thus allowing garbage to creep into the database;

3) high cost of blanket updates to the data which might be required by application design changes.

Generally, I only consider e-blob for non-essential data which is going to vary by installation, or for specially structured data which is infrequently updated and thus works well with special index types which work with blobs.