3 ms·
I don't want to look at it in any particular way. I was asking for clarification, to see whether I understand the features correctly, and to determine what cus
by pjlegato 11y ago
I don't want to look at it in any particular way.
I was asking for clarification, to see whether I understand the features correctly, and to determine what customers get by using your product.
So the question remains: what does the customer get beyond using, say, Mongo? You say it's a relational database, but the Schema-On-Need feature sounds awfully NoSQLish. What's the point of using a fixed schema at all if it simply creates new fields on demand whenever you try to insert a nonexistent field? Why not just use Mongo in that case?
Having a new query language that some people like is nice, but how do you plan to build a company around that?
Why is it different or better than the hundreds of other query languages out there?
- david927 11y agoThanks for getting back to me -- to be honest, the question as it stood was confusing for me. Ok, I see what you're asking now and I apologize for not asking for more clarification. It's a really good question as are the additional questions here, so let me get to it. Do you remember when DropBox was announced on HN? One of the top responses was, "1. For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software." MongoDB, like most NoSQL stores, is hard to maintain, complex to query. To make the same query in the example above may be easy for you but it's not easy for most. You might think, therefore, that you're not the target market. I want to convince you you're wrong. You're going to love this. First, as you know Schema-On-Need is not just about adding fields on demand but also about changing the mapping cardinality on demand, and then being able to query that in a clear and simple way. That's one of the big changes this query language brings. If you are maintaining a list of Films, you'd be forgiven for expecting only one Director per film, but "Delicatessen" a 1991 French film has two: Jean-Pierre Jeunet and Marc Caro. If you query Film : Director.Name = "Jean-Pierre Jeunet" you'll get that and "Amelie" for example. You'll get all films where Jean-Pierre Jeunet was one of the directors. But if you want only films which were directed by both Jean-Pierre Jeunet and Marc Caro, you would say Film : Director.Name ^=^ ("Jean-Pierre Jeunet","Marc Caro"). Variations of that same operator will give you either one of those directors or films where directors are both but can be others. The query language also maps very nicely to be used in a BI tool. I'll try to get some examples of that to you, but I think that reason alone is extraordinarily compelling. The final reason why I think you'll come to love Brodlist will be when you use it. I'm going to make one more analogy if you promise not to shoot me for it. When Google came along, it was just another search engine among hundreds. And explaining the Page Rank algorithm didn't convince many people. But that changed when it was used and the hundreds of other search engines dissipated. My point is simply that hundreds of competitors can reflect not that it's solved, but possibly the opposite: that it's still unsolved. And the other point is that I can talk about it for a long time but what I'm looking forward to most is the chance to prove it to you.