Comments for Bradley Holt

Comment on Joining Cloudant by Alan Seiden

2014-09-29T19:50:55Z

Congratulations, Bradley! Sounds like a perfect fit. Hope to see you soon (ZendCon etc.).

Alan

Comment on Northeast PHP Conference 2014 by Northeast PHP Conference 2014 | PHP Information

2014-08-21T17:25:55Z

[…] The Northeast PHP Conference 2014 in Cambridge, Massachusetts is just over two weeks away (Saturday, September 6th and Sunday, September 7th). We’ve got a great lineup of talks this year including talks on coding standards, content strategy, unit testing, PHP 5.6 (and beyond), leadership and teamwork, object-oriented programming, …read more […]

Comment on Why Gigabit Matters by Chris

2013-01-24T20:08:15Z

Some more coverage here: http://www.nytimes.com/2013/01/24/opinion/how-to-get-high-speed-internet-to-all-americans.html?smid=tw-share&_r=0

Comment on Entity Relationships in a Document Database at ZendCon 2012 by Lukas Smith

2012-11-21T16:32:45Z

Just FYI .. its also Doctrine CouchDB ODM. Basically in the Doctrine project we call everything that implements the Doctrine Common Persistence interfaces on top of a “document store” ODM.

BTW there is also Doctrine PHPCR ODM and there is even an implementation on top of OrientDB which also implements these interfaces, which might also be moved to the Doctrine organization eventually.

Since you mentioned a CMS as a use case on one of the early slides, PHPCR ODM is actually optimized for the CMS problem domain.

Comment on Domain-Driven Design at ZendCon 2012 by Domain-Driven Design at ZendCon 2012 – Bradley Holt | Helseo

2012-11-21T12:00:45Z

[…] site: Domain-Driven Design at ZendCon 2012 – Bradley Holt This entry was posted in domain and tagged domain by admin. Bookmark the […]

Comment on Entity Relationships in a Document Database by Bradley Holt

2012-08-14T14:51:20Z

@jonathan: Thanks! Glad you found it helpful. As for the performance of UUIDs, I talked a bit about this in my Scaling CouchDB book. For best performance, you’ll want to use mostly monotonic (basically means sequential) document identifiers. This has to do with the underlying B-tree structure used to store documents. UUIDs are mostly monotonic while still working in a distributed environment, but other approaches could work as well. This is mainly a concern when dealing with large data sets.

Comment on Entity Relationships in a Document Database by jonathan

2012-08-13T13:32:05Z

Great slides, very helpful, for all of us coming from the SQL world.
Quick question – on the “Additional Techniques” page you mention that UUIDs have better performance than natural keys. Can you elaborate on this? (or at least point me to where I could do some reading on it?)

Comment on The MVC Paradox by MattiMatti

2012-06-21T08:48:12Z

I’m using Slim + Redbean + (Twig)* to create simple services for flash apps. especially if i don’t have svn support and console access on the production server.

I’m used to develop php using zend + doctrine + (smarty|twig) and for sure are oversized for this kind of projects.

About testing, it depends on you practice. i’m used to it so i develop all the business logic into worker classes, leaving to the microframework just the routing and input validation.

That’s my experience!

Comment on Entity Relationships in a Document Database by Bradley Holt

2012-05-20T21:03:13Z

@phil westwell: You’re welcome! A fundamental limitation of document databases is that you cannot have atomic transactions across document boundaries. There are very good reasons for this limitation—this limitation brings with it great benefits in the forms of availability and partition tolerance. However, this limitation is a critical one to understand when designing your application and database. So, the short answer is that there is no solution to the problem you mention. If your relationships must be consistent, then they must be in one document. This, of course, precludes use of the Relationship Document pattern.

The slightly longer answer is to use the List of Keys pattern instead (assuming we’re talking about a Many to Many relationship here). This solves the problem for one side of the relationship—the side on which you store the List of Keys—but you still have the problem on the other side of the relationship. Note that when you move from the Relationship Documents pattern to the List of Keys Pattern you are giving up availability (increased probability of document update conflicts) in exchange for consistency. Broadly speaking, document databases are a good fit when availability is more important than consistency. If you must have this level of consistency, then perhaps a document database isn’t a good fit—but note what you’re giving up in terms of availability and partition tolerance.

Comment on Entity Relationships in a Document Database by phil westwell

2012-05-20T16:13:12Z

Thanks for posting this. I think formalising the idea of “view collation” helps think certain problems through.

I thought the “Relationship Document” idea was interesting, but I have some doubts about how it would work in practice that I hope you can clear up.

Say the author document already exists and I want to create a book document. So I (i) use a PUT to add the book and then (ii) use a PUT to add the book-author relationship document.

But if step (ii) fails, then I have a book that has no author. Do you envisage a solution to deal with this?