3 ms·

That is interesting, thanks. As you can probably imagine, I fall in the build business logic into data with constraints at the schema layer. Yes, I understand

by LukeEF 6y ago

That is interesting, thanks. As you can probably imagine, I fall in the build business logic into data with constraints at the schema layer. Yes, I understand that FB have a bunch of MySQL instances with a hacked graph layer - same in other places. Makes the case for native solutions and I think that is why Dgraph exist. Graph will become the base, because it does everything an RDBMS can do and some more.

oldandtired 6y ago
When you state "Graph will become the base, because it does everything an RDBMS can do and some more.", you show that you fail to understand what an RDBMS is and that there is NO commercially available RDBMS around. There are significant differences between SQL DBMS's and RDBMS. The other thing you have also forgotten, is that you can rewrite your statement as "RDBMS will become the base, because it does everything a Graph can do and some more." The last part of this "and some more" makes both statements equally false. Or if you view it in another way, equally true. These things are tools that we have available to us so that we can solve the various problems laid before us.
- verdverm 6y ago
  I thought lunch was free :[
verdverm 6y ago
For me, it's less about SQL v GQL and more about the maturity and scalability of the underlying tech, Postgresql has everything I need except for niche applications. I too put BI, rules, and shapes in the schema or design. I'm choosing to express this with Cue and generate the tech specific schemas, types, and code from that. A database will never fit this role because the better definitions span tech and would be forcing concerns upon a DB schema that don't belong there (like data presentation to a user in a UI). Then there is the whole data lake perspective and a BI engine which can span tech and stores, paired with how enterprise companies operate... they like SQL based queries which can work on data across their legacy appliances. Analysts know SQL.

by LukeEF 6y ago

oldandtired 6y ago

When you state "Graph will become the base, because it does everything an RDBMS can do and some more.", you show that you fail to understand what an RDBMS is and that there is NO commercially available RDBMS around. There are significant differences between SQL DBMS's and RDBMS. The other thing you have also forgotten, is that you can rewrite your statement as "RDBMS will become the base, because it does everything a Graph can do and some more." The last part of this "and some more" makes both statements equally false. Or if you view it in another way, equally true. These things are tools that we have available to us so that we can solve the various problems laid before us.

verdverm 6y ago
I thought lunch was free :[

verdverm 6y ago

For me, it's less about SQL v GQL and more about the maturity and scalability of the underlying tech, Postgresql has everything I need except for niche applications. I too put BI, rules, and shapes in the schema or design. I'm choosing to express this with Cue and generate the tech specific schemas, types, and code from that. A database will never fit this role because the better definitions span tech and would be forcing concerns upon a DB schema that don't belong there (like data presentation to a user in a UI). Then there is the whole data lake perspective and a BI engine which can span tech and stores, paired with how enterprise companies operate... they like SQL based queries which can work on data across their legacy appliances. Analysts know SQL.