42 ms·

> Why on earth would you use a database that makes so little in the way of guarantees about what results you get from it? Because some people can't stand havin

• toomuchtodo 10y ago
  Who knew you'd need to learn how to use tools to use them!
  • deleted 10y ago
    [deleted]
  • blitzkriegpunk 10y ago
    Get. Out. Of. Town.
• im_down_w_otp 10y ago
  Is having seen something used some way a leading indicator of it being a good idea to have used that thing that way? Because I've seen Excel used as database with all kinds of macros and VBA scripts bolted-on/embedded to provide the workbook various shapes of stored-procedure and query capability... but, while sorta impressive in a "Holy crap, lol wut?" kind of way, I'm not sure any instance I observed of uses like that were actually good ideas. Full of epic cleverness and ingenuity? Definitely. A good idea? Probably not.
  • jdavis703 10y ago
    Did they make the company a lot more money than they cost? If so they were probably a good idea. Not all code needs to be "pretty" to serve a purpose. I've seen some pretty epic hacks that I know generated hundreds of thousands of dollars of new revenue.
    • im_down_w_otp 10y ago
      They often had a significant "bus factor" problem as a result of this in the best cases, and in the worst cases these mountains of hacks were a massive impediment to growth and/or evolution to meet changing marketplace demands... despite being a central pillar of data management and revenue as it existed in the status quo.
  • rhizome 10y ago
    In my experience in market research, advanced spreadsheet programming with macros and pivot tables and whatnot are more a contemporary incarnation of Reporting than raw database querying and operations.
• hk__2 10y ago
  It’s useful for prototyping. When you don’t know which schema you’ll end up using having an *SQL database is tedious because you have to do migrations every time you change the schema. Once you’re done prototyping you can switch to a better alternative.
  • kinkdr 10y ago
    Exactly. Use the right tool for the right job. Start prototyping and development with MongoDB and then migrate to Postgres, or Cassandra or whatever suits your user-case better.
    • kinkdr 10y ago
      Oops.. did I say something wrong?
  • balfirevic 10y ago
    How does that work? If you need to preserve data between the application versions then you still get all the headaches with MongoDb (either migrating the data or supporting multiple schema versions when you read the data, oh the fun!). If you don't need to preserve data between the versions then you don't need to write migrations scripts in SQL, just scrape everything and pretend it's the first version of application.
  • collyw 10y ago
    I have never managed to build a prototype that didn't end up being used in a production setting. I am trying to remember if I ever built a prototype that got rewritten. Probably not.
    • hk__2 10y ago
      It probably won’t get rewritten but the DB-specific code is in one module so it’s easy(-ish) to swap the underlying DB.
  • PeterisP 10y ago
    In that case you can start with postgres and stuff your documents in a single json column, accessing it just as you would have in mongo while you're prototyping and don't care about speed and indexing, and when you're done, you can just change that table to a more proper structure without changing databases.
• sandGorgon 10y ago
  in this case, please use Postgresql jsonb data tables. Just as powerful as mongo... but with the stability and guarantees of postgres
  • ptman 10y ago
    It has been pointed out before that json(b) has problems with indexing. IIRC the cost estimates of indexes on JSON data are static, and therefore very rarely accurate. I'm terribly sorry but couldn't find a reference with 5min of searching. I still like postgres over mongo
    • Someone 10y ago
      http://postgresql.nabble.com/working-around-JSONB-s-lack-of-stats-td5835595.html http://postgresql.nabble.com/working-around-JSONB-s-lack-of-... Of course, that doesn't mean indexes never help. See for example http://blog.2ndquadrant.com/jsonb-type-performance-postgresql-9-4/ http://blog.2ndquadrant.com/jsonb-type-performance-postgresq.... I guess the workaround would be creating indexes on computed columns that query from the json data, together with changing one's queries to use that computed field. For example, with a json column storing names in various places, a computed column could collect all of them in an array. An index on that computed column will have good statistics. Bottom-line: if you want your queries to run fast, you will have to tell your store what kind of data you have and what kind of queries you will run. Otherwise, there's little the store can do. Having a traditional database with various constraints is a way to give that information. With json columns, you may have to do it in another way (for now).
• m_mueller 10y ago
  So my question is then: Why not use CouchDB instead? I don't see what Mongo gives you over that and CouchDB is at least dependable and predictable in its operation.
  • rdtsc 10y ago
    CouchDB is too reliable and actually fsyncs your documents to disk. That is plain boring. I like to live on the edge and have some documents go to /dev/null once in a while. Life is just more exciting that way ;-) /s
  • SmirkingRevenge 10y ago
    I really like Couch, I wish it had more adoption than it seems to have and that its ecosystem was more mature than it seems to be... and that javascript wasn't its first class citizen. But its a really cool database (though I'm partial to rethinkdb now)
    • derefr 10y ago
      Even Javascript is sort of a second-class citizen in Couch. The real first-class citizen is native Erlang code running unsandboxed in the server context. If you want high(er) performance, that's where you go. (Alternatives to this have been discussed, like embedding the luerl Lua interpreter to give the option of a sandboxed programming target without the IPC cost. Nothing in the immediate pipeline, though.)
    • dkersten 10y ago
      though I'm partial to rethinkdb now Me too. RethinkDB is my document database of choice these days. In my experience, its proven to be reliable and fast and the development team very responsive and helpful. They also seem quite mindful when it comes to new features and will delay things for years (eg auto-failover, which they now support but it took a while) if rushing it would impact quality. That's what I want from a database: first and foremost it must be solid and not lose my data. Everything else (including high availability) can come after.
  • s_kilk 10y ago
• Lazare 10y ago
  > Because some people can't stand having to work with SQL,migrations,schema and constraints The thing is, if you actually try and write an app using MongoDB, you will rapidly find that you: 1) Have migrations (except they're going to be some scary ad hoc nodejs script that loop through your document store and modify fields on the fly). 2) Have schemas (except they'll be implicit and undocumented) 3) Constraints (except they'll be hidden inside your app logic, and violating them will cause data corruption). The biggest lie about NoSQL databases is that they're schemaless. If you're EVER going to read the data back and do anything with it, it has a schema.
  • catnaroek 10y ago
    Exactly. While the process of designing the structure of your data can make you feel like “you're not getting real work done”, in the long run, it actually prevents headaches caused by inconsistent data. Data always has a structure, it's just that some people are too lazy or mentally feeble to figure out what it is.
    • collyw 10y ago
      For me that is the most important aspect of starting / designing an application. If the data model is accurate, then the code falls into place easily. If its not quite right, more and more code ends up in the application trying to make up for the poor data model.
      • varunom 10y ago
        I second this. My first task in any project is to design the whole data model based on current requirements and while designing it I think of the interfaces and how would they read and write data (to refine requirements). Writing views and actions/APIs on top of well-formed data model then becomes a breeze.
        • collyw 10y ago
          Its so un-agile (but it works).
• catnaroek 10y ago
  > Because some people can't stand having to work with SQL,migrations,schema and constraints The real question is “How come these people are allowed anywhere near data stores?” SQL isn't ideal, but how many of the alternatives are better at protecting the integrity of your data?
  • EpicEng 10y ago
    Thank you. Not everything is easy. This is the difference between engineering and 'hacking'. Hacking is not something to aspire to; it's something you do because of crushing, external pressures.
    • 1879325237 10y ago
      Hacking is trying to get the SQL representation into something programmers use via the way of an ORM. At the end of the day, a SQL database doesn't represent the data in a way the programmer uses the data. It has to be transformed and that is a bigger hack than loosening some constraints.
      • orf 10y ago
        > At the end of the day, a SQL database doesn't represent the data in a way the programmer uses the data. Errrr that's exactly what they do, unless you've got a terrible schema and havent thought about your data enough. The thing is about 'sql databases' is you can use the power of sql to fetch the data in any representation you want.
      • catnaroek 10y ago
        ORMs are a really bad attempt to force a square peg into a round hole. The mismatch between the relational model and object-oriented design principles is simply too big. In the relational model: (0) A relation is a collection of tuples of primitive values. Every relation has a relation schema, which determines the arity of its tuples and the type of each tuple component. In other words, the relational model is first-order. (1) There are a few basic operators for computing relations from other relations (relational algebra). (2) There is a mathematical theory (database normalization) of how to design primitive relation schemas to avoid storing duplicate information, and running into insertion, update and deletion anomalies. On the other hand, in a pure object-oriented program: (0) An object is a collection of data and operations on it. The data is hidden from the rest of the program, so the only way to operate on it is to use the object's operations. The operations may take objects as arguments and return objects as results, so objects are intrinsically higher-order. (1) In general, there are no limits on how one can define a single object's operations. However, it's impossible to define operations which require knowledge of the internal representation of two or more objects at a time. (2) There are heuristic guidelines (e.g., SOLID principles) for designing flexible object-oriented systems. However, they lack any sort of rigorous foundation beyond “it seems to work in practice”, so object-oriented designers may deviate from these guidelines at their own discretion. --- For data-oriented applications, it's pretty clear to me that the relational model has important advantages over object-orientation: (0) The decoupling between data and operations allows the database designer to focus exclusively on data integrity constraints, instead of anticipating whatever queries users will want to make. (1) The limited expressiveness of relational algebra (with no recursively defined relations) is also a blessing, because it makes automated query optimization tractable in practice. While objects present problem after problem: (0) Object graphs are intrinsically directed, and must be traversed in the direction of its links. This makes queries less declarative. (1) Objects have a notion of identity, which destroys many opportunities for using equational reasoning to build large queries. This also makes queries less declarative. Of course, the relational model says nothing about general-purpose programming, whereas object-orientation does. But there exist other paradigms for general-purpose programming that are less badly in conflict with the relational model. For instance, functional and logic programming: (0) Don't reject the use of first-order data, decoupled from operations. (1) Prefer the notion of mathematical variable, whose meaning is given by substitution (a first-order operation), to imperative assignment, whose meaning is given by certain predicate transformers (intrinsically higher-order gadgets).
• partycoder 10y ago
  Using a document oriented data store as a log aggregator? Please lord, take him in his sleep.
  • btown 10y ago
    It does work for a certain volume of data. You can index fields you're interested in, even do so after the fact, and it's like any other database in that case. And sometimes you have small apps that do need complete historical log data, so Kafka et al just introduce unnecessary complexity since you'd need to aggregate into a key value store anyways. But if you do this, god forbid you go beyond where indices can fit in RAM of a single machine. And you will do so, with probability one given your product doesn't shut down. So you're running a gauntlet against a redesign.
    • deleted 10y ago
      [deleted]
    • partycoder 10y ago
      Try some Lucene based software and tell me how it goes.
• chris_wot 10y ago
  So get them to use ToroDB.
  • dkersten 10y ago
    Never heard of ToroDB. Just checked out the website and it looks interesting, however the tagline "The first NoSQL and SQL database" is untrue. At least OrientDB has had both schema+schema-free and SQL + NoSQL querying interfaces. That is, you can optionally supply a schema for your documents. IIRC you could choose either schemaless, schema or mixed (where mixed allows fields not in the schema to exist as schemaless fields). The default query language was SQL with "enhancements" (to allow for graph traversal), but you could also query with Gremlin. Not sure if this is still the case or not as I don't use OrientDB. The above was true in 2012 and possibly a lot earlier. I see ToroDB's first Github commit was in 2014.
    • ahachete 10y ago
      We have rectified the web site. No longer says "first", just states now the fact that its open source. Thanks!
• creshal 10y ago
  > Because some people can't stand having to work with SQL,migrations,schema and constraints, it's as simple as that So use an ORM that understands Postgres' JSON columns. Don't need to write a single SQL statement, automagic migrations, no explicit schema (unless you make one), no constraints (unless you add them). It works great, we did a rather large project last year using Django's ORM and postgres where we didn't know the final data schema until months after launch.
• zamalek 10y ago
  > some people can't stand having to work with SQL,migrations,schema and constraints, it's as simple as that Use the right tool for the job, right? Admittedly something like MongoDB could be the right tool for the job (examples around here include RethinkDB and CouchDB). MongoDB, however, is like a hammer with no head.