3 ms·

Because all you need most of the time is a flat stream of characters. You don't need any of the DB crap, no random access, no indexes, no structure.

by sklogic 12y ago

superuser2 12y ago
It depends on the problem domain you are working in. I can't think of an application I've done where this wouldn't have required complex serialization and parsing. Those tools are already built for me in the form of ORMs and RDMSes. Why should I write my own?
- sklogic 12y ago
  > It depends on the problem domain you are working in. Unix is a pretty general purpose thing. And yet, you won't find anything in it that needs a database, nothing at all among hundreds of applications, including some fairly complex ones, like CAD/CAE tools, IDEs, compilers, etc. > I can't think of an application I've done where this wouldn't have required complex serialization and parsing. Are you doing CRUD mostly? > Those tools are already built for me in the form of ORMs and RDMSes. Why should I write my own? Parsing?!? In ORMs and DBMSes?!? C'mon, try to parse me some C++ with your Oracle.
  - SamReidHughes 12y ago
    > Parsing?!? In ORMs and DBMSes?!? Yes. Stuff stored in files has to be parsed when you read it out of files.
    - sklogic 12y ago
      And how exactly RDBMS crap could help with parsing? Mind parsing a C++ source file with your RDBMS?
      - SamReidHughes 12y ago
        The grandparent was talking about the serialization and parsing of the data that you'd be storing in flat files, not parsing of C++ files. Work that you avoid by using a DBMS.
        sklogic 12y ago
        Parsing text files is not a problem at all. Never been a problem. And there are far too many benefits of having flat text streams vs. some inaccessible stupid binary ad hoc formats hidden inside some enterprisey RDBMS guts.
  - duaneb 12y ago
    > Unix is a pretty general purpose thing. Yea, until you want to query a normalized data set. Then unix is pretty miserable, because text is very ill-suited for indices and rapid and/or random access.
    - sklogic 12y ago
      Turns out, you need to do such things pretty rarely. Not "most of the time", as RDMBS proponents claim.
  - superuser2 12y ago
    >Parsing?!? In ORMs and DBMSes?!? What exactly do you think a database does? Provides a way to durably store tabular data on disk and read it back. Without a database, I have to make that myself by writing serialization routines to put my data structures on disk and parsing routines to go from "stream of characters" to my data structures. DMBS places some limits on your data structures but does all that for you.
    - sklogic 12y ago
      If serialisation is hard for you, then you probably doing something badly wrong. In the tools I'm using it's done by a single line of code. And since most of the time data structures are trees or graphs, being sledgehammered into a tabular structure is not pleasant at all.
eropple 12y ago
Maybe you can replace a document database with the file system (though reinventing indexes for reasonable performance--which in so many use cases becomes remarkably important past a few hundreds of thousands of records--will be fun for you), but modeling relational concepts on the file system is both hard and time-consuming. And I'm comfortable saying that most nontrivial business applications are fundamentally relational.
- sklogic 12y ago
  > And I'm comfortable saying that most nontrivial business applications are fundamentally relational. Now try to assess, how many applications are supposed to be "nontrivial business applications". It's quite a niche thing, and that's where all this DBMS stuff belongs to. Please do not impose this crap on the rest of the world, we don't need your CRUD.
  - eropple 12y ago
    Why are you so randomly hostile about this? Your tone and attitude are super shitty throughout this thread. Chill. As for CRUD--I'm a platform and devops engineer. I'm not a web developer (except incidentally). But I do often write relational things--like, say, "I have this node, running this application, using this artifact from that data store"--that are best modeled by a relational data store. They're otherwise trivial applications, but reinventing the relational data store would take orders of magnitude longer than writing the application against SQLite or Postgres. How do you propose to model relations across the file system in a way that doesn't make it the tail wagging the dog? While I'm thinking about it, I'm pretty comfortable going further than "nontrivial business applications" to "a majority of networked applications". The world is relational. Modeling it relationally makes a lot of sense for a lot of use cases.
    - sklogic 12y ago
      No, it's RDBMS proponents who are hostile. Their attitude is "you will be assimilated, resistance is futile, we already won, so shut up and obey". This cannot and will not be tolerated. I was pressured many times into giving up doing things the right way and adopting RDBMSes, and that was not pleasant at all. In some cases someone else who picked up that projects tried to move to RDBMSes (from hierarchical or document-oriented storages used before) and failed miserably. So, again, I never came across anything that would need a relational storage. Not even when I was doing heavily distributed HPC (which is as "networked" as it gets). Yes, of course I did a lot of things that are relational naturally - but all of them were in Datalog, with no storage required. Btw., wtf is "devops"? I've heard this a number of times recently, but nobody could explain the meaning.

Because all you need most of the time is a flat stream of characters. You don't need any of the DB crap, no random access, no indexes, no structure.

by sklogic 12y ago

Because all you need most of the time is a flat stream of characters. You don't need any of the DB crap, no random access, no indexes, no structure.

superuser2 12y ago

It depends on the problem domain you are working in. I can't think of an application I've done where this wouldn't have required complex serialization and parsing. Those tools are already built for me in the form of ORMs and RDMSes. Why should I write my own?

sklogic 12y ago
> It depends on the problem domain you are working in. Unix is a pretty general purpose thing. And yet, you won't find anything in it that needs a database, nothing at all among hundreds of applications, including some fairly complex ones, like CAD/CAE tools, IDEs, compilers, etc. > I can't think of an application I've done where this wouldn't have required complex serialization and parsing. Are you doing CRUD mostly? > Those tools are already built for me in the form of ORMs and RDMSes. Why should I write my own? Parsing?!? In ORMs and DBMSes?!? C'mon, try to parse me some C++ with your Oracle.
- SamReidHughes 12y ago
  > Parsing?!? In ORMs and DBMSes?!? Yes. Stuff stored in files has to be parsed when you read it out of files.
  - sklogic 12y ago
    And how exactly RDBMS crap could help with parsing? Mind parsing a C++ source file with your RDBMS?
    - SamReidHughes 12y ago
      The grandparent was talking about the serialization and parsing of the data that you'd be storing in flat files, not parsing of C++ files. Work that you avoid by using a DBMS.
      - sklogic 12y ago
        Parsing text files is not a problem at all. Never been a problem. And there are far too many benefits of having flat text streams vs. some inaccessible stupid binary ad hoc formats hidden inside some enterprisey RDBMS guts.
- duaneb 12y ago
  > Unix is a pretty general purpose thing. Yea, until you want to query a normalized data set. Then unix is pretty miserable, because text is very ill-suited for indices and rapid and/or random access.
  - sklogic 12y ago
    Turns out, you need to do such things pretty rarely. Not "most of the time", as RDMBS proponents claim.
- superuser2 12y ago
  >Parsing?!? In ORMs and DBMSes?!? What exactly do you think a database does? Provides a way to durably store tabular data on disk and read it back. Without a database, I have to make that myself by writing serialization routines to put my data structures on disk and parsing routines to go from "stream of characters" to my data structures. DMBS places some limits on your data structures but does all that for you.
  - sklogic 12y ago
    If serialisation is hard for you, then you probably doing something badly wrong. In the tools I'm using it's done by a single line of code. And since most of the time data structures are trees or graphs, being sledgehammered into a tabular structure is not pleasant at all.

eropple 12y ago

Maybe you can replace a document database with the file system (though reinventing indexes for reasonable performance--which in so many use cases becomes remarkably important past a few hundreds of thousands of records--will be fun for you), but modeling relational concepts on the file system is both hard and time-consuming. And I'm comfortable saying that most nontrivial business applications are fundamentally relational.

sklogic 12y ago
> And I'm comfortable saying that most nontrivial business applications are fundamentally relational. Now try to assess, how many applications are supposed to be "nontrivial business applications". It's quite a niche thing, and that's where all this DBMS stuff belongs to. Please do not impose this crap on the rest of the world, we don't need your CRUD.
- eropple 12y ago
  Why are you so randomly hostile about this? Your tone and attitude are super shitty throughout this thread. Chill. As for CRUD--I'm a platform and devops engineer. I'm not a web developer (except incidentally). But I do often write relational things--like, say, "I have this node, running this application, using this artifact from that data store"--that are best modeled by a relational data store. They're otherwise trivial applications, but reinventing the relational data store would take orders of magnitude longer than writing the application against SQLite or Postgres. How do you propose to model relations across the file system in a way that doesn't make it the tail wagging the dog? While I'm thinking about it, I'm pretty comfortable going further than "nontrivial business applications" to "a majority of networked applications". The world is relational. Modeling it relationally makes a lot of sense for a lot of use cases.
  - sklogic 12y ago
    No, it's RDBMS proponents who are hostile. Their attitude is "you will be assimilated, resistance is futile, we already won, so shut up and obey". This cannot and will not be tolerated. I was pressured many times into giving up doing things the right way and adopting RDBMSes, and that was not pleasant at all. In some cases someone else who picked up that projects tried to move to RDBMSes (from hierarchical or document-oriented storages used before) and failed miserably. So, again, I never came across anything that would need a relational storage. Not even when I was doing heavily distributed HPC (which is as "networked" as it gets). Yes, of course I did a lot of things that are relational naturally - but all of them were in Datalog, with no storage required. Btw., wtf is "devops"? I've heard this a number of times recently, but nobody could explain the meaning.