Rapid schema development with PostgreSQL

https://speakerdeck.com/andrewgodwin/rapid-schema-development-with-postgresql

by pearkes • 13 years ago

104 53 13 years ago

josephlord2• 13 years ago

Hmmm... I'm having evil thoughts about putting a whole web application including templating inside of Postgres and just exposing a few functions via a web interface.

Don't worry I won't do it really but does anyone worry that Postgres is doing too much and that focus might be lost on being a reliable and fast relational DB? I haven't seen any signs of problems but I do have this slight concern with all the array/hstore/json features they have been adding recently.

mclarke• 13 years ago

I think it's impressive how quickly the Postgres world was able to adapt to the shifting needs of webapps and the whole nosql thing. The latest JSON features are a natural extension of the key-value & array stuff that has been around for years.

There's also a bunch of working focusing on replication enhancements that is underway; adding first-party replication tooling will be a huge reliability improvement for Postgres clusters.

I don't think it's that they lost focus, it's that the project is picking up steam.

josephlord2• 13 years ago

Yes you are probably right. I really like Postgres, the attitude (reliability, standards etc.), the documentation, basically everything and don't want it to change too much.

threeseed• 13 years ago

Interesting. I believe that PostgreSQL hasn't moved quickly enough.

After all these years they still don't have a clear and coherent clustering or sharing story.

IsTom• 13 years ago

I guess C++-like philosophy of "pay (with performance) only for what you use" applies here. If you're not using hstore/json/v8 it probably won't affect you. Also they keep doing solid work on the SQL front, just see http://www.postgresql.org/docs/devel/static/release-9-3.html.

drbawb• 13 years ago

I was a little hesitant to use hstore in my latest project, but it ended up being really cool.

I'm basically storing a trees of metadata that catalogs, in this case, a "season" of television as a root and then each individual episode as a leaf.

What I thought was really cool was that I can store the object references (as a self-referential foreign key) outside of the hstore: this means that the join I use when fetching the tree is still indexed and very inexpensive.

However the actual metadata itself is stored as an hstore payload -- which can be indexed in addition to being part of your query. The only downside is you lose a bit of typesafety since hstore is `text->text`.

It let me throw an application together without committing to a rigid schema, which was nice -- and it actually ends up being pretty easy to work with.

I just thought it was really cool how easy it was to separate the unstructured data, and the well-structured relation of that data.

joevandyk3• 13 years ago

Postgresql 9.4 will likely extend hstore to store things other than strings.

http://obartunov.livejournal.com/172503.html

asdasf• 13 years ago

That isn't evil at all, and I saw someone was actually working on doing that. For web apps that just need to expose a json api, we already just generate boilerplate code from the database anyways, we literally don't write any code for the webapp.

Postgresql continues to be better in real practical ways for us every release. I haven't see any features cause problems or interfere with other features. I am not concerned that it is going to happen.

jmspring• 13 years ago

It isn't quite the same, but a large amount of configuration and content gets commingled in Drupal databases. It can make for interesting upgrade / migration challenges if you aren't careful.

einhverfr11• 13 years ago

I think you could turn JSON into XML with a little work, and then run xslt on it in the db ;-)

Don't worry I won't do it really but does anyone worry that Postgres is doing too much and that focus might be lost on being a reliable and fast relational DB?

Not really. PostgreSQL has never been a purely relational DB. See table inheritance for example (another feature very easily misused but which makes some very difficult things very possible).

nsitarz• 13 years ago

I'm pretty sure that "ALTER TABLE ... ADD COLUMN ... NULL;" holds an AccessExclusiveLock on the relation being altered for the duration of the transaction in PG 9.1 and 9.2. Is there some trick to the zero downtime schema changes that are mentioned in this slide deck? I only ask because I recently had to get creative with zero downtime schema migrations for my current project.

gwy• 13 years ago

I believe the AccessExclusive is only if you are setting to NOT NULL, such as "ALTER TABLE my_table ADD COLUMN my_col boolean NOT NULL DEFAULT false"

We were just down for 56 hours due to our 3rd party platform vendor applying that type of update.

AFAICT the only workaround is to do it in steps: set the DEFAULT, fill existing rows with the default, then apply the NOT NULL constraint (which will still lock it for a full table scan to check the validity of the constraint).

joevandyk3• 13 years ago

ALTER TABLE always creates the AccessExclusive lock.

If you add a 'not null default something' to the column, it'll rewrite the whole table, which can take some time. And since the table has the AccessExclusive lock, this is what will block reads/writes.

Doesn't matter for small tables.

For large tables, you want to add the column without a not null or default, commit that transaction, then populate the data, then add the not null and default constraint.

moron4hire7• 13 years ago

I'm failing to see the utility of hstore or json over adding nullable columns here, especially if the latest version makes adding a nullable column essentially instantaneous. It doesn't seem to simplifying the handling of missing/unavailable data, but does manage to complicate the SQL syntax.

I have clients that use a variety of databases for a variety of reasons, not the least of which is "just because that is where our data is." All the value of most projects is in the data, and the value of data grows with age, because you cannot recreate the past. If you lose something or you fail to record something, then you can't ever get it back in a way that will stand up to audit scrutiny. This has the awful effect of making technology-specific details of databases get pushed into the business-decision realm, rather than the technology-decision realm.

So complicating the SQL syntax is a significant issue for me. Sticking to as much standard, ANSI SQL as possible makes my programs more portable across RDBMSes. With some of the tools I've written, I can make a full transition from MySQL to MS SQL Server and back again and the application doesn't care. Having that sort of power makes upgrading your database a technology decision, not a business one.

Yes, the features that Postgres have are nice, but to me they represent a very great chance of vendor lockin. I don't believe that the Postgres team will ever pull anything to make me hate them, but then I thought the same about Sun at one point, too.

tieTYT2• 13 years ago

http://www.postgresql.org/docs/9.2/static/datatype-json.html

Such data can also be stored as text, but the json data type has the advantage of checking that each stored value is a valid JSON value. There are also related support functions available

moron4hire7• 13 years ago

That doesn't answer my question. Storing structured data in any single-field, be it checked or unchecked, violates the first normal form, if you're going to be querying directly on sub-fields of that field. If the json document is just getting exported out to the client without any inspection of the document from the SQL side, then it's fine and I see the point of having a JSON type that can validate the data. But to extend the SQL syntax to allow for querying sub-fields of that data is the wrong solution to the problem.

SQL Server has had this feature for quite some time as well, in the ability to store and query on XML documents. It's awful. The few times that it has "saved the day" on certain queries just because the data was already stored as XML, it turned out to be a false profit and became a serious issue down the road.

rpedela2• 13 years ago

I just see it like all applications and libraries that adhere to some standard. Some adhere strictly to the standard whatever that is. Some do that but also add more features to push the industry forward. NVIDIA does that for graphics. Mozilla does that for browsers. Looks like PostgreSQL is starting to take that role with relational databases.

I generally view it as a good thing unless you care about cross-platform. If you do, then don't use the non-standard features.

moron4hire7• 13 years ago

But how is that different from the old MS battle-cry "embrace, extend, extinguish"? It's the "extinguish" part I'm concerned about.

einhverfr11• 13 years ago

Looks like PostgreSQL is starting to take that role with relational databases.

PostgreSQL has been doing this for a long time. It started, actually, as a research project for how to manage very complex forms of data in a relational-like database (many people use it as a purely relational database but that doesn't even begin to scratch the surface of what PostgreSQL can do).

DrJokepu3• 13 years ago

HStore and especially JSON are useful because they allow you to store complex data structures fairly easily. Do you have something that contains a number of somethings that contain a number of somethings that contain a number of somethings? Normally you would need like, 4 tables to store this and carefully planned queries to work with them efficiently. However, if the object graph has no external references (besides the top-level object) you can just safely shove the whole thing into a JSON without losing referential integrity.

Your reasons are very valid however so obviously you have to think about the consequences before using non-standard features. However, not using advanced or novel features (which non-standard features tend to be) can also lead to stagnation and loss of competitiveness so you have to also be careful with being careful, if that makes sense.

testing12341234• 13 years ago

I'm not very familiar with the JSON datatype in postgres. Is it possible to update subvalues without writing the entire JSON bag?

For example: {"a": 1, "b": 2} (in psuedocode)

User 1: select JSON

User 2 select JSON

User 1: update JSON set "a" = 11

User 2: update JSON set "b" = 22

What would the value of the JSON column be after that. In other systems I've worked in (where it's JSON in a database column), the answer is {"a": 1, "b", 22} or a failure on the second update letting the client know that their copy is out of date.

I'd love to know if postgres can deal with this in the normal relational way so that the result is actually {"a": 11, "b": 22}

memracom• 13 years ago

Most people would say that PostgreSQL gives you the same portability that you have with your app, but at a different level. You can port your PostgreSQL database from a Linux server to a Windows server and back again and your application doesn't care. But because you are porting at the db layer, your application could leverage a bunch of PostgreSQL features that are very useful. As a developer, this might not matter a lot to you, but as a company, who relies on its data and expects longevity from its systems, this kind of thing matters a lot. PostgreSQL is a technology that you can rely on in the long haul and you will not be held hostage to a technology owner whose interests are not aligned with yours.

Herbert22• 13 years ago

Anecdotal, I migrated a sluggish multi table SQL Server setup to a single table PostgreSQL by replacing the previous EAV setup with hstore and m2m "article-tag" tables with array fields. Exactly the same functionality, only 20x faster. Sometimes vendor lockin is worth it :)

jeffdavis• 13 years ago

It's not a major architectural change or anything; it's just a convenience for some users.

It may not be a great idea for everyone to use it. But it doesn't strike me as a really bad idea, either.

Postgres offers among the closest to standard SQL you can get if that's what you want.

einhverfr11• 13 years ago

I'm failing to see the utility of hstore or json over adding nullable columns here

Well, for example, they make a good way to store user defined fields.

So complicating the SQL syntax is a significant issue for me. Sticking to as much standard, ANSI SQL as possible makes my programs more portable across RDBMSes. With some of the tools I've written, I can make a full transition from MySQL to MS SQL Server and back again and the application doesn't care. Having that sort of power makes upgrading your database a technology decision, not a business one.

I think the tradeoff is between having a database for multiple apps and having an app for multiple RDBMS's. If you are going to go with the former, absolutely avoid every PostgreSQL-ism. But if you want to make a more generally useful to an organization, you need a more intelligent database and that means going to things like user defined functions, complex triggers and more.

moron4hire7• 13 years ago

It's not really any different of code, though. It's the same wrongness of CoffeeScript vs. JavaScript: there is no paradigm shift, it just adorns the same old dog chow with a slightly different set of ASCII characters. Postgres is turning into Foxpro, from the opposite direction. Foxpro was this BASIC sort of application language thing that had delusions of grandeur to be a database, too. Postgres is growing delusions of grandeur for being an applications programming language, too.

craigkerstiens• 13 years ago

If you're looking to try Postgres as a full on document store there's more and more tooling around making this feasible. Here's one newer gem that makes it pretty straightforward for Rails: https://github.com/webnuts/post_json

CraigJPerry• 13 years ago

When would the hybrid schema approach be useful?

To my mind it doesn't offer any extra ability to add or remove columns over what we have already.

E.g. I'd never write select * I'd always name columns in my query so that I can be immune to reordering or adding columns to the underlying table or view.

einhverfr11• 13 years ago

Where we are looking at it in LedgerSMB is to allow user defined extra fields for forms. A previous approach was a framework for managing join tables, but json would be much cleaner.

Rapid schema development with PostgreSQL

Related Stories