kfool

8 ms·

1.
by kfool 14y ago
- schema. Maintaining schema and dependencies is hell on all but a small system When you have the tools you have the power.
2.
by kfool 15y ago
ChronicDB is not only a hosted solution. It also runs locally.
3.
by kfool 15y ago
Sorry for not disclosing I work on ChronicDB. The author of the 6b article kindly provided more information about the time it took for the migration: http://news.ycombinator.com/item?id=3621561 A couple of limitations of the Percona tool
4.
by kfool 15y ago
The toolkit documentation reports limitations. What they really needed is ChronicDB http://chronicdb.com
5.
by kfool 15y ago
NoSQL does not support flexibility of schema change. http://chronicdb.com/blogs/nosql_is_technologically_inferior... . Flexibility of schema definition and flexibility of schema change are two different things. Defining schemas only involv
6.
ChronicDB offers public SQL gateway over HTTP(chronicdb.com)
1 points by kfool 15y ago|0 comments
7.
by kfool 15y ago
The issue is not performance. The issue is backward compatibility. ALTER TABLE performance will eventually improve. PostgreSQL 9.1 lifts-off the lock-up limitation. But what a performant ALTER TABLE will not improve is its intrusiveness to
8.
Anonymous SQL(chronicdb.com)
2 points by kfool 15y ago|0 comments
9.
by kfool 15y ago
Which part of the Slicehost to Rackspace migration required the additional time that had not been invested? Also, what do BCC and AR refer to?
10.
Should an RDBMS be a proper Unix tool?(briantheprogrammer.com)
2 points by kfool 15y ago|0 comments
11.
by kfool 15y ago
Now it's time to bring the idea beyond code Exactly! Try versioning data with ChronicDB: http://chronicdb.com
12.
by kfool 15y ago
Referential integrity is to databases what pointers are to code. You definitely need it. What's worse than migrations? Being unable to turn an application off, since it uses the old schema. With ChronicDB we support indefinite backward comp
13.
by kfool 15y ago
Version data, like source code. $ chd version mydb $ chd revert -d <txn_id> mydb Neither replication nor backups protect from accidentally deleting data. And restoring from binary logs requires downtime. http://chronicdb.c
14.
by kfool 15y ago
Not always. An app requiring non-trivial SQL can be an indication of a problem requiring non-trivial workflows. If the problem is complex, you want to model relations, not ignore them. (But clearly not in this hairy query.)
15.
by kfool 15y ago
> "because of the schema-less models." > "I find migrations painful and unnecessary." A schema-less model neither makes a migration less painful nor eliminates it. In MongoDB, what did you do when the data model changed?
16.
by kfool 15y ago
(Disclaimer: I work on ChronicDB) I second that: schema-less is misunderstood. There's a difference between flexibility of schema definition and flexibility of schema change[1]. Flexibility of schema change, which NoSQL does not solve, is i
17.
Change is not the enemy(chronicdb.com)
1 points by kfool 15y ago|0 comments
18.
Undelete from whoops;(chronicdb.com)
1 points by kfool 15y ago|0 comments
19.
by kfool 15y ago
This can be handled by deleting orders from the logical representation, yet preserving them in the historical layer.
20.
by kfool 15y ago
That's one of the things ChronicDB does. It makes historical values available in the average application.
21.
by kfool 15y ago
Was there something specific it the data model that made the versioning hard to write? Or was it that, for this to work across the board, the entire model had to be versioned? It sounds that SQL itself wasn't the problem. Were you looking f
22.
by kfool 15y ago
Isolating databases behind APIs and rev-ing API+schema separately is not enough. When the schema changes, data must be transformed to match the new schema version. As you point out this takes too long with a large database, and it doesn't a
23.
by kfool 15y ago
Good point. With databases distributing data in-memory across machines, shared memory becomes the database. Don't be surprised if Arc runs HackerNews on distributed memory some day... But one has to wonder, what happens when you need to upg
24.
by kfool 15y ago
Very well put. It is not access type (direct vs indirect) that make schema improvements hard, but access preservation: availability. And indeed copying the data often leads to one or more of the copies being wrong, unless special measures a
25.
by kfool 15y ago
Here is how I see things: 1. Updates should not only be applied in sequence. It is better to produce a binary diff between any two versions, and apply only that (one) binary diff. The reason for this isn't efficiency, but semantics. Updates
26.
by kfool 15y ago
I would suggest neither the what nor the where, but the whom. If your supervisor's background does not intimitate you, and you don't desperately want to become like them, then find someone else.
27.
NoSQL Is Technologically Inferior To SQL(chronicdb.com)
10 points by kfool 15y ago|9 comments
28.
by kfool 15y ago
ChronicDB could help here http://chronicdb.com
29.
by kfool 16y ago
My sister applied for the Winter 2011 batch with me as a co-founder. Frankly, her idea puts to shame all ideas I've ever had. In my opinion, women possess a unique perspective of what people may want. With 99% of founders being male, it sou
30.
by kfool 16y ago
The maintainer does not specify a version and expects the automatic process of determining minimumum dependencies to take over. But it takes over with dependencies of newer versions than necessary.

More ›