4 ms·

Yes. I think many here miss totally the point. Is the same mindset that lead to believe C, bash or unix are good(?) then why bother? I'm very lucky that I sta

by mamcx 7y ago

Yes. I think many here miss totally the point. Is the same mindset that lead to believe C, bash or unix are good(?) then why bother? I'm very lucky that I start with FoxPro, so I know what is to live with a MUCH better thing than SQL. To the point: - "SQL is standard, everywhere... why try to change or do something else?" I hope none here work in new software products. And also, try to replace ALL the OLD with the NEW is no the point, is to try to DO BETTER THAN THE OLD. I suspect most of use are in that business... right? - "SQL is a good language!" Superficially, yes.. as good is javascript or C. More exactly to be the "default" option we are VERY lucky SQL is not alike C or JS. But "good" is not. Is adecuate. IF you DON'T KNOW WHY then learn the why first. For us that LIVE in the RDBMS world is clear as water than SQL is not the ideal, is what we have. ---- Is important to understand that "SQL", Rdbms and the relational model are badly misunderstood (just look how the NoSql movement market itself!) - SQL IS NOT THE RELATIONAL MODEL, is BASED on it. The relational model is MORE expressive, powerful, flexible and EASIER than SQL. - SQL IS NOT RDBMS A much better APIs can be build on top a RDBMS but SQL is a poor language for that. This is part of why exist so many extensions. Think, for example, why you can't do SELECT key FROM BTreeInde_CustomerCode GROUP BY (whatever -- And I mean GROUP, not SUMMARIZE!) let city = SELECT name let filter = WHERE id = @id let query = city + filter(id=1) and many many other things like that Many things that get mixed with the "SQL" language are part of the implementation or capabilities of the RDBMS. - However, SQL IS A FINE EXAMPLE IN HOW DO DATA And in fact, is not that hard to imagine a much better version, SQL is not that far from a better option!

tracer4201 7y ago
I didn’t really understand your post other than a high level point that you believe SQL is insufficient. I’m not quite understanding the benefit of your example. I don’t personally want to write that style of syntax.
- mamcx 7y ago
  > you believe SQL is insufficient I don't believe it, is insufficient, as a fact. Compare let city = SELECT name let filter = WHERE id = @id to let city = map name let filter = filter(id = id) let query = city |> filter this is to show that SQL, despite being a programming language, can't compose well. The syntax is not the point. You can build full apps in forth or lisp (as examples of even more minimal Langs than SQL) but now consider the idea of build a full app in SQL. Without other language making the rest of their limitations.
  - tracer4201 7y ago
    You’re asking me to consider the idea of building a full app in SQL. I would ask you - why? SQL wasn’t designed nor ever meant to be able to write a full app. You’re expecting it to do something it wasn’t designed to do. Because it is a programming language doesn’t necessarily mean it ought to be able to solve any kind of problem. I personally don’t think SQL is all that great, for various reasons (lack of standardization with various dialects and their own gaps or abilities).
    - mamcx 7y ago
      > You’re asking me to consider the idea of building a full app in SQL. I would ask you - why? "We Can Do Better Than SQL" And the fact that some can't imagine to build a full app in SQL (not as is TODAY but as could BE) is sad. I live in that world before. With the base/foxpro familia's you can totally build a full app with a database language, in fact, easier than with python. --- The point here is that obviously, SQL is not mean for programming, but do one-off queries here and there. But it not exist a reason to aim higher. BTW, part of the laments of the creators of the relational model is that SQL have ruined, like COBOL, the mind of millions of developers.
      - tracer4201 7y ago
        >”And the fact that some can’t imagine to build a full app in SQL is sad” You are outlining some general purpose programming language that allows querying, information retrieval, maybe declaratively or functionally or using objects? I don’t know - you provide no other details. How expressive would this language be? What abstractions would it provide out of the box? How expressive is it? Your examples allow some code reuse via naming/aliasing specific clauses... is that it? Specifically what apps would it allow someone to build? And what trade offs result from those decisions? Is it better suited for mathematical operations or data science vs building general enterprise applications? There’s a difference. Is it interpreted like SQL? Would it need to be compiled? You’re doing a lot of handwaving, and when pressed for details, you respond with a thinly veiled insult - the problem is with the reader or me specifically for not being able to read you mind. We should take you at face value without question. Good luck with that attitude in your career.
taeric 7y ago
Agreed with the sibling. Large chance I have just missed your goal. It may help to expand on your proposal. For example, what do you mean with group by, but not summarize? The group by clause says nothing about how to combine data not in the group. That has to be on the select. And I have yet to find a solution that beats ROLLUP for giving a great overview of data. About the only thing that sucks on the current syntax is that it is not possible to get auto complete in the select, without having some from.
- mamcx 7y ago
  > What do you mean with group by/ ROLLUP ROLLUP is not the same than groups. With [1:a 1:b 2:a] Group by (as is normaly in other langs): [1:[a,b] 2:[a]] Sql "group by" instead is for summary/tally of data: [1:2 2:1] //assuming count ROLLUP is for make a nice report! [1:[a,b] Count:2; 2:[a] Count:1] What SQL lacks (in this case), but the relational model not, is the ability to nest relations as easily as JSON. ---- Part of the deceptive power of SQL is that is very adequate and for "just query" of data is ok for most cases. But as "programming language" it lacks some extra power and versatility.
  - MarkusWinand 7y ago
    > What SQL lacks (in this case), but the relational model not, is the ability to nest relations as easily as JSON. SQL has nested relations since SQL:2003[1] (called multisets). They are not widley supported and frankly speaking I don't like them. JSON was finally added with SQL:2016[2]. [1] https://sigmodrecord.org/publications/sigmodRecord/0403/E.JimAndrew-standard.pdf https://sigmodrecord.org/publications/sigmodRecord/0403/E.Ji... [2] https://modern-sql.com/blog/2017-06/whats-new-in-sql-2016#json https://modern-sql.com/blog/2017-06/whats-new-in-sql-2016#js...
  - taeric 7y ago
    This feels like a misunderstanding of SQL. It is not a programming language. It is a data selection language. And group by does work the same as other languages. However, you can't talk of the group by without the select. So, if you use count, or sum, or max, or ..., Yes it will be a summary. You can use string_agg or friends if you want all values. But... Probably safer to get each as a row.
lincpa 7y ago
I worked as a Foxpro programmer for 18 years. I later switched to the Clojure language for 8 years. I used the functional programming language Clojure as SuperFoxpro, which is very easy to use and enjoyable. I has formed a new programming idea ---- `Everything is Foxpro (RMDB)`. ;-) I advocate: Building a relational data model on top of hash-map to achieve a combination of NoSQL and RMDB advantages. This is actually a reverse implementation of posgtresql. [Clojure is a functional programming language based on relational database theory](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/Clojure_is_FP_based_on_RMDB.md https://github.com/linpengcheng/PurefunctionPipelineDataflow...) [Everything is RMDB](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/Everything_is_RMDB.md https://github.com/linpengcheng/PurefunctionPipelineDataflow...) [Implement relational data model and programming based on hash-map (NoSQL)](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/relational_model_on_hashmap.md https://github.com/linpengcheng/PurefunctionPipelineDataflow...)
- mamcx 7y ago
  Excellent take. The functional model is not too far.
mamcx 7y ago
Because the poor formatting and example (making the code look too much as sql!), some nuance was lost. Consider instead: let keys = SELECT key FROM BTreeIndex_CustomerCode; let city = SELECT name; let groups = GROUP BY (whatever -- And I mean GROUP, not SUMMARIZE!); let filter = WHERE id = @id; let query = city + filter(id=1); for city in query GROUP BY keys ....
porker 7y ago
> I'm very lucky that I start with FoxPro, so I know what is to live with a MUCH better thing than SQL. For us who didn't use FoxPro, why was it MUCH better than SQL?

by mamcx 7y ago

tracer4201 7y ago

I didn’t really understand your post other than a high level point that you believe SQL is insufficient. I’m not quite understanding the benefit of your example. I don’t personally want to write that style of syntax.

mamcx 7y ago
> you believe SQL is insufficient I don't believe it, is insufficient, as a fact. Compare let city = SELECT name let filter = WHERE id = @id to let city = map name let filter = filter(id = id) let query = city |> filter this is to show that SQL, despite being a programming language, can't compose well. The syntax is not the point. You can build full apps in forth or lisp (as examples of even more minimal Langs than SQL) but now consider the idea of build a full app in SQL. Without other language making the rest of their limitations.
- tracer4201 7y ago
  You’re asking me to consider the idea of building a full app in SQL. I would ask you - why? SQL wasn’t designed nor ever meant to be able to write a full app. You’re expecting it to do something it wasn’t designed to do. Because it is a programming language doesn’t necessarily mean it ought to be able to solve any kind of problem. I personally don’t think SQL is all that great, for various reasons (lack of standardization with various dialects and their own gaps or abilities).
  - mamcx 7y ago
    > You’re asking me to consider the idea of building a full app in SQL. I would ask you - why? "We Can Do Better Than SQL" And the fact that some can't imagine to build a full app in SQL (not as is TODAY but as could BE) is sad. I live in that world before. With the base/foxpro familia's you can totally build a full app with a database language, in fact, easier than with python. --- The point here is that obviously, SQL is not mean for programming, but do one-off queries here and there. But it not exist a reason to aim higher. BTW, part of the laments of the creators of the relational model is that SQL have ruined, like COBOL, the mind of millions of developers.
    - tracer4201 7y ago
      >”And the fact that some can’t imagine to build a full app in SQL is sad” You are outlining some general purpose programming language that allows querying, information retrieval, maybe declaratively or functionally or using objects? I don’t know - you provide no other details. How expressive would this language be? What abstractions would it provide out of the box? How expressive is it? Your examples allow some code reuse via naming/aliasing specific clauses... is that it? Specifically what apps would it allow someone to build? And what trade offs result from those decisions? Is it better suited for mathematical operations or data science vs building general enterprise applications? There’s a difference. Is it interpreted like SQL? Would it need to be compiled? You’re doing a lot of handwaving, and when pressed for details, you respond with a thinly veiled insult - the problem is with the reader or me specifically for not being able to read you mind. We should take you at face value without question. Good luck with that attitude in your career.

taeric 7y ago

Agreed with the sibling. Large chance I have just missed your goal. It may help to expand on your proposal. For example, what do you mean with group by, but not summarize? The group by clause says nothing about how to combine data not in the group. That has to be on the select. And I have yet to find a solution that beats ROLLUP for giving a great overview of data. About the only thing that sucks on the current syntax is that it is not possible to get auto complete in the select, without having some from.

mamcx 7y ago
> What do you mean with group by/ ROLLUP ROLLUP is not the same than groups. With [1:a 1:b 2:a] Group by (as is normaly in other langs): [1:[a,b] 2:[a]] Sql "group by" instead is for summary/tally of data: [1:2 2:1] //assuming count ROLLUP is for make a nice report! [1:[a,b] Count:2; 2:[a] Count:1] What SQL lacks (in this case), but the relational model not, is the ability to nest relations as easily as JSON. ---- Part of the deceptive power of SQL is that is very adequate and for "just query" of data is ok for most cases. But as "programming language" it lacks some extra power and versatility.
- MarkusWinand 7y ago
  > What SQL lacks (in this case), but the relational model not, is the ability to nest relations as easily as JSON. SQL has nested relations since SQL:2003[1] (called multisets). They are not widley supported and frankly speaking I don't like them. JSON was finally added with SQL:2016[2]. [1] https://sigmodrecord.org/publications/sigmodRecord/0403/E.JimAndrew-standard.pdf https://sigmodrecord.org/publications/sigmodRecord/0403/E.Ji... [2] https://modern-sql.com/blog/2017-06/whats-new-in-sql-2016#json https://modern-sql.com/blog/2017-06/whats-new-in-sql-2016#js...
- taeric 7y ago
  This feels like a misunderstanding of SQL. It is not a programming language. It is a data selection language. And group by does work the same as other languages. However, you can't talk of the group by without the select. So, if you use count, or sum, or max, or ..., Yes it will be a summary. You can use string_agg or friends if you want all values. But... Probably safer to get each as a row.

lincpa 7y ago

I worked as a Foxpro programmer for 18 years. I later switched to the Clojure language for 8 years. I used the functional programming language Clojure as SuperFoxpro, which is very easy to use and enjoyable. I has formed a new programming idea ---- `Everything is Foxpro (RMDB)`. ;-) I advocate: Building a relational data model on top of hash-map to achieve a combination of NoSQL and RMDB advantages. This is actually a reverse implementation of posgtresql. [Clojure is a functional programming language based on relational database theory](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/Clojure_is_FP_based_on_RMDB.md https://github.com/linpengcheng/PurefunctionPipelineDataflow...) [Everything is RMDB](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/Everything_is_RMDB.md https://github.com/linpengcheng/PurefunctionPipelineDataflow...) [Implement relational data model and programming based on hash-map (NoSQL)](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/relational_model_on_hashmap.md https://github.com/linpengcheng/PurefunctionPipelineDataflow...)

mamcx 7y ago
Excellent take. The functional model is not too far.

mamcx 7y ago

Because the poor formatting and example (making the code look too much as sql!), some nuance was lost. Consider instead: let keys = SELECT key FROM BTreeIndex_CustomerCode; let city = SELECT name; let groups = GROUP BY (whatever -- And I mean GROUP, not SUMMARIZE!); let filter = WHERE id = @id; let query = city + filter(id=1); for city in query GROUP BY keys ....

porker 7y ago

> I'm very lucky that I start with FoxPro, so I know what is to live with a MUCH better thing than SQL. For us who didn't use FoxPro, why was it MUCH better than SQL?