the database revolution has just been unfolding rapidly over the last half century, and I was really privileged to take a part in it. SQL didn't cause this revolution; it was caused by [Music] economics. Hi Don, welcome to the show. Hi Richie, thank you, pleasure to be here. I'd love to start by just finding out how you first became interested in databases. Well, I'll start from the beginning. In 1970, I was finishing my Graduate Studies at Stanford, and I took my first professional job with IBM at the Watson Research Center in New Yorktown Heights, New York. I moved from California to New York in the winter, which was not a move I'd recommend if you enjoy warm weather. A few months later, my friend Bray Boyce also completed his graduate work at Purdue, and he joined IBM at the same location where I was. Well, Yorktown was the Central research facility of IBM, and the mission of IBM research is to study technologies that might influence IBM's future products.

1970 uh there was kind of Revolution going on. The cost of computing was coming down very quickly and lots of companies were putting data online for the first time. This seemed like a business opportunity. So uh the group that Ray and I were in was assigned to study the state-of-the-art in database management with an eye to influencing IBM's future products. Okay, and what was this uh first database that you got interested in? Well, we studied something called the dbtg report. So let me tell you where that came from and why we were interested in it. Uh in the early 1970s, the most respected person in the database industry was a guy named Charles Bachman of General Electric, known to his friends as Charlie. And Charlie had actually invented the concept of a database management system. He was the first one to call for a separate software layer to manage data that was shared by multiple applications. And this was a pretty important concept. And for inventing the database management system basically uh Charlie received the ACM touring award, which is

the most prestigious award in computer science. Well, Charlie had actually built a database management system that was called IDs. Stood for integrated data store and IDs stored information in the form of records and connection connections between records. You could think of them as pointers. Uh, in in in IDs a program could navigate through what Charlie called Data space, moving from one record to another by following these pointers to find an answer to a question. And in fact, when Charlie gave his touring award lecture, he titled it the programmer as Navigator. Well, one of the most popular business programming langu languages at the time was Cobalt, and there was a movement to add database management functions to Cobalt. And a committee was formed for this purpose called the database task group, was abbreviated dbtg. Charlie was a member of dbtg, and the group published a report in 1971, uh, defining a set of commands for navigating in data space based on Charlie's ideas. Well, the dbtg report was was pretty important at the time. Ray and I spent some time studying it. It was wonderfully complicated. It had currency.

indicators set of current selection rules. It had a fine command with seven different versions. It could do a pretty good job of answering questions that were anticipated in the database design, but for unanticipated questions, sometimes you were out of luck. Ray and I wrote a review of the dbtg report, and we suggested some incremental improvements. We thought if we could manage to understand something as complicated as dbtg, our careers would be off to a good start. That's funny. I love the analogy there of working with data as being navigating. I think it's a phrase that is not often used, but you do spend so much time trying to work out how different bits of data are connected together. It sounds like this idea of data being connected is leading towards the idea of relationships between data and relational databases. So, can you talk me through how relational databases came about and how you got interested in them? Well, sure. All this came about because of a paper written by Ted C. Ted was a scientist at IBM's

research laboratory in San Jose, California. In June of 1970, he published what became a very famous paper called A Relational Model of Data for Large Shared Data Banks. The basic point of Ted's paper was that Charlie Bman had gotten it all wrong, and that navigating through data space was a bad idea. Ted thought that database queries should not look like programs that tell the computer what to do. He wanted to express queries in a high-level, non-procedural language. He liked to say, Tell me what you want, not how to find it. Well, I read Ted's paper as part of my learning process in getting up to speed on the state-of-the-art in databases, and on first reading, I wasn't much impressed with this paper. Ted was basically a mathematician, and his paper contained a lot of mathematical jargon. It defined a relation as a subset of the Cartesian product of a set of domains, and it introduced concepts like data independence and normalization, and operators like permutation, projection, and join. My impression of all this

was that card's paper was interesting from a theoretical point of view, but I couldn't see that it was really grounded in practical engineering. But I kept on hearing more about this relational data model. I heard about a symposium that was going to be held in Miami Beach in December of 1972, and it was going to feature a tutorial on relational database. Well, traveling to Miami in the winter had a certain appeal, so I got permission to attend this. The symposium was called the COINS '72 Symposium Conference on Information Systems, and I actually met Ted Codd for the first time on the beach at Fountain Blue Hotel. I attended the tutorial, which was taught by Chris Date, and I have to describe it as a conversion experience. For the first time, I began to understand the simplicity, power, and elegance of Ted's relational approach. Queries that took a whole page in of code in DBTG could often be expressed in a single line in a relational approach. So when I returned to New

York. I wasn't interested in dbtg anymore. I was piing up a new interest in relational query languages. That's fascinating, and I love that. Even though it was a hugely influential paper, your first reaction to Ted work with like, Oh, it's just mathematical nonsense, all theoretical, no practical applications. But once you sort of see it's in action, it is actually incredibly powerful. So I love how it just translates into something more practical and more real. I think the first sort of real implementation of this was the System R project that you worked on. Is that right? Well, there were actually several things going on, more or less at the same time, in different places in IBM and also at other different companies. There was the Ingress project, for example, at Berkeley. But I'm going to talk mainly about System R because that was the project that I was associated with. There were a lot of people who saw the power and simplicity of cod's approach, but the whole idea depended.

on a high level of query language with an optimizing compiler that could turn it into efficient code. And the question was that sounds like a good idea, but was it just science fiction, or was it really ready for prime time? And in 1973, IBM decided to answer this question by building an industrial-strength relational system just to prove it could be done. And this was done at IBM Research. They created a project for this purpose and called it System R. Well, System R was located in San Jose because that's where Ted Codd was. And there were about 14 people, including Ray and myself, who were gathered from several IBM sites all over the country to come together and work on this System R project. Well, I wasn't very happy about moving to New York at that time. I'm sorry about moving from New York to San Jose at that time. I had just bought a house, and my wife had a good job teaching high school. I felt kind of disrupted, but I made the move and went to San Jose to join the System R.

project, and that turned out to be the best decision I ever made. Um, working on IBM's first relational database system really turned out to be the opportunity of life. Um, it's interesting how these cross-country moves have been problematic each time, but yeah, Stanford, I've been moved, that's the legend. Um, and then from here, from System R, it seems like this is leaning towards the really important paper that you wrote around the SQL programming language. So where did that idea come from? Well, to tell you the truth, Ray and I liked some parts of Codd's ideas better than others. We really liked this idea of a nonprocedural query with SQL and tell me what you want and not how to find it. What we didn't like was the mathematical jargon in Ted's papers. We wanted to design a language for a new class of user. Uh, we called them casual users. Uh, we thought a casual user is a professional who needs access to data but he doesn't want to be a computer programmer and he doesn't even

want to rely on a computer program. He might be an urban planner, a financial analyst, or an insurance company executive, and he might have questions that vary from day to day, and he might want his results pretty quickly. Well, the database systems of the 1970s just didn't meet these requirements. So, to serve this casual user, Ry and I wanted to design a new language, and we set certain goals for it. Number one, we wanted to use the term tables instead of relations - everybody knows what a table is. Number two, we wanted to base the language on ordinary English words like select and goal. Number three, the language should have no special symbols, and it should be easy to type on a keyboard. And goal number four, which is maybe the most challenging one, we wanted it to have something that we called the walk-up-and-read property, meaning in simple cases, a user with no special training should be able to understand a query just by reading it. Well, those were the goals that we set for ourselves, and we called this new language

sequel, which was an acronym for Structured English Query Language. It's amazing how the things you were worrying about back then 50 years ago are things that we're still worrying about now. So, for example, there's a big push at the moment to make data more accessible to everyone, regardless of whether you have a technical background or not. And I find it fascinating that this is something you worried about when you were first designing the SQL language - that people who didn't have this strong mathematical background could still make use of the technology. So, you mentioned the idea of walk up and read. So, people just walk up, look at the code, and it makes sense to them. It sounds like a difficult thing to measure. So, how do you know if you've been successful at that? That's a good question. It's a hard thing to do and it's a hard thing to measure. And I'll never really know how successful we were. But we had a psychologist on the staff named Phyllis Reer, and Phyllis conducted an

experiment at San Jose State University uh teaching SQL to college students who had no programming experience at all, and recording their progress and the kinds of errors that they made uh turned out that these college students could become proficient in SQL after a few hours of instruction. Uh their most common error was something funny; they would forget to put quotes around strings. Uh so for example, if a query contained the phrase name equals Fred, you had to put quotes around Fred to indicate that it's a constant string, somebody's name, rather than the name of a column. Uh well, that's an important distinction, but a lot of students never understood it and uh intended not to put quotes around anything. I can confirm that that is still a problem in every programming language 50 years later: forgetting to quote your strings and putting bits of syntax in the wrong place. Um so after um you've sort of designed this language, I think it was initially used uh just within uh IBM. How did it um travel outside this um outside that organization? Well, R and I published the

first uh SQL paper at a conference called Sig fep in Ann Arbor Michigan in June of 1974 uh SIGET has since changed its name to SIGMOD the Special Interest Group on Management of Data and it's now uh probably the most prestigious annual database conference uh this conference in 1974 was very interesting because it featured a panel discussion between Ted cut and Charlie Baka uh now this was called a panel discussion but everybody knew it was a debate and in my view uh Ted Cod was the uh was the winner of this debate I think after this conference in 1974 uh Ted's relational approach was considered to be the new mainstream in database management so that's why I consider that this year 1974 starts the clock on what I've called 50 years of relational databases and since the first SQL paper appeared in this conference uh it also kind of starts the clock on 50 years of SQL I have a question for you on this because the in this paper on SQL it's spelled SE qu El now been shortened even

today there's a lot of confusion about do I call it SQL do I call it SQL i' really love to have an official answer on this uh which do you prefer well at some point uh after publishing our paper we got a uh a letter from somebody's lawyer that said we couldn't use the name SQL anymore it was somebody's registered trademark so we had to officially shorten the name to SQL which stood for structured query language uh so the official name of the language is now SQL but SQL is a lot easier to say than SQL so I usually just pronounce pronounce the name SQL and uh and hope I won't get in any trouble for doing that all right we have an official answer there that's pretty I like that both ways are possible one's better for writing and one's better for speaking um so uh when I interrupt you you uh talking about the SQL paper can you tell me what happened uh once the paper was um published actually the the next thing that happened was was a tragedy um that

sequel paper was the last thing that Ray Boyce and I did together. Less than a month after the Sig for de conference, my friend Ray died suddenly and unexpectedly of a brain aneurism. It's a very sad event, and even 50 years later, it feels like a real tragedy. So, I'm sure it must have been a shock to you. Could you maybe tell me a bit about what it was like working with Ry? Yeah, Ry was my best friend. We moved from New York to California together. We lived near each other, we carpooled to work. I drove R to work at IBM on the day he had his aneurysm attack, and he was taken away in an ambulance. Ray and I used to play something we called the query game. We were experimenting with different query language designs. We take turns dreaming up queries and challenging each other to express them. We explored a lot of ideas in those days, and at the end of the day, we couldn't remember which one of us was responsible.

for any given idea, uh collaborating with Ray was the best part of my job. That's wonderful that you have fond memories of working with him. And again, yeah, I'm sorry, I'm sorry that such a tragedy happened to and to your friend. I'm wondering, um, so after You' had this sort of revolutionary paper, um, things are starting to get popular or who were the first people that took on this idea, who was using SQL to begin with. Well, you have to remember that System R was a research prototype. It was not an IBM product, uh, so you couldn't just go somewhere and buy it. Um, as a research group, uh, we wanted to gain some visibility inside IBM, and to do that, we needed to have some users. So we distributed System R to about a dozen internal IBM sites and also on a joint study basis to three, uh, Frontline IBM customers. That was Boeing and Pratt Whitney and upjn. And we had quarterly meetings with all of our, uh, users to learn about their experiences and respond to their suggestions. Uh, it was during this period

uh that we uh had to shorten the uh the name to uh to SQL. Okay, so it a a lawsuit that I intervene there there Dar lawers um oh ah okay um all right so uh to begin with it was a research project, and then when was SQL first commercialized? Well, since SQL was invented at IBM research, you might expect that IBM would be the first to bring it to Market, but that's not actually the way it turned out. Interestingly enough, uh IBM in those days had another database product called IMS, and they weren't in a hurry to introduce a competitor to their successful product, uh but they did allow the systemar group to publish their results in the open technical literature, uh that was generous, and that's how we published the SQL paper and lots of other papers about the details of the system our work. Well, there was a small startup company, uh uh called relational software Incorporated, abbreviated RSI, that took an interest in these papers, uh the founders of RSI guessed correctly that IBM would eventually

release a SQL product on mainframe computers, and they saw an opportunity there. They decided to build a product that was compatible with SQL on less expensive hardware platforms and to bring it to the market quickly. They executed this plan very successfully. In 1979, they released a SQL product called Oracle, running on a minicomputer, a PDP-1. This product was immediately successful, so much so that RSI changed its name to the Oracle company. Oracle was actually the first commercial implementation of SQL. That's fascinating because I've not heard of RSI, but obviously Oracle is a huge brand name. So I realized about the name change. IBM itself didn't release a SQL product until 1981 on some of its smaller computers. That was two years after Oracle, and their strategic mainframe product called DB2 came out in 1983. That was four years after Oracle, and by this time, well, Oracle had pretty much established a commanding lead in the database market. Okay, so it seems like that was

the main competition then was between Oracle and IBM in the early days. Were there any other players? Yeah, there were. I've been talking about System R, a research project to prove the concept of a commercial relational system, but there was another project very much like that also going on at the same time at UC Berkeley. Their project was called Ingres, and it was led by two professors, Mike Stonebreaker and Eugene Wong. Ingres had its own high-level query language called Quel, and much like System R, Ingres was distributed for free to experimental users, which were mainly universities, and it became widely used as a teaching tool at universities. Ingres spun off a commercial company also called Ingres in 1980, and in the early 1980s, Ingres and Oracle were the market leaders in relational databases. They kind of ran neck and neck. They both ran on DEC V computers. Ingres implemented the Quel language, and Oracle implemented SQL. The Quel language was well

liked by its users. But I think I'd give the edge to the Oracle marketing divisions. They marketed their SQL product very aggressively. And in 1984, Ingres decided that they had to begin supporting SQL in order to compete with Oracle. Okay, so I didn't realize that there were all these sort of alternate languages then for accessing relational databases. But it seems within a few years things have become standardized because you had the advent of a standard for the SQL language. Can you tell me how that came about and what your involvement was in? Yeah, that I think that's an interesting story. The American National Standards Institute (ANSI) created a committee in the late 1970s to define a standard database language. They kept changing the name of this committee, but usually had H2 in its name somewhere. So I'm going to call it the H2 committee. Well, at first this standard was supposed to be based on DBTG. But in 1982, they decided to extend

the mission to define a relational standard also they wind up with two different standards. One based on dbtg and also a relational one. And when they got into the relational business, uh, the uh, two companies that were in the marketplace for relational systems were Oracle and Ingres, and they were both marketing SQL. And so the H2 committee decided that they would base their relational standard on some version of SQL. They went ahead and created a standard, which became an ANSI standard and also an international standard with ISO. Uh, these were named database language SQL SQL and and they were released in 1986. So that was going on, uh, in NC and ISO, which were uh, voluntary associations of commercial entities companies. But actually, the standards work that had the most impact in my opinion was something that was going on somewhere else. It was at the National Institute of Standards and Technology (NIST), sometimes pronounced NIST. And unlike NC, uh, NIST is actually a branch of the federal government. And in 1992, NIST created something called a Federal Information Processing Standard. This one was called FIPS.

127 that happen to be identical to the ANSI SQL stand uh and even more important they provided a test suite and a validation service for conformance to this standard and companies whose database product passed the validation test received a license to sell their products to the federal government well several companies did this and uh and this gave a big boost to the commercial presence of the SQL language because you could sell it to the government well the SQL standard has evolved a lot over the last 50 years it started out pretty simple and it just keep growing uh a lot of new features have been added uh data and time data types outer joins recursive queries the list goes on and on uh a new revision has come out about every five years uh the latest one came out in 2023 I think the standardization product has has had several good effects on the industry uh number one it gave customers confidence that they had multiple sources where they could buy their database software uh number two it gave vendors a way to evolve their products while maintaining compatibility with each

other and number three it brought some really smart people together to evaluate requirements and make proposals. This, uh, H2 SQL standards committee has been, uh, meeting on a regular basis, uh, for, uh, for a long time now, many years. I love that, um, the fact that the language became standardized helped increase adoption because it gives people trust that this is an official thing and that you know what you're getting, um, so that, that seem like a pretty important Milestone. I'm wondering, are there any other important milestones in the early history of sequel that you think are important? Sure, uh, before we leave the standards, um, uh, subject, I want to give a disclaimer here, uh, uh, during the decade of the 80s, uh, when a lot of this standard work was being done, I actually took a leave from the database world and got involved in desktop publishing. That seemed to me to be the exciting thing that was happening in the 1980s, uh, but IBM finally decided not to go into that business, so, uh, so I returned to the database world, uh, around

1990, but by that time, a lot of the standards work had already been done. So, uh, credit for that to other people. Well, during the 1980s, the revolution in data management, uh, really hit full stride. The cost of computing and storage kept on coming down. The volume of J data generated by businesses, uh, just expanded enormously. Uh, almost every business system, almost every business needed to acquire a system to manage their data. Oracle, of course, continued to prosper, but lots of other new relational products entered the market. There was DB2 and Informix and Cbase and Tandem and Microsoft SQL Server. They all offered implementations of the SQL language, seemed to be ring the market for everybody. In fact, so many products were claiming to be relational that in 1985, Ted Cod published a series of 12 rules that define an authentic relational database. And you can find these rules in Wikipedia. Just, uh, just search for Cod's 12 rules. But starting in the 1990s, there were some truly game-changing

developments three very high-quality open-source SQL implementations became available. Their names were MySQL, PostgresSQL, and SQLite, and all three of these were fully-featured, reliable, high-performance systems with large user communities. They all had free versions and also they had additional services that you could buy for a fee. Well, web-based applications were proliferating in the 1990s, that was the dot-com days, and many of these apps used one of these open-source systems for data management. SQLite in particular is interesting because it's embedded invisibly all over the place. It's in most smartphones and browsers and many popular applications. So these three open-source SQL systems are now among the most widely used database systems in the world, absolutely. They are currently popular through them and these are things that we still teach now on DataCamp. If you want to learn to use databases, you use Postgres, one of these other ones. So yeah, it's had a huge impact

actually, even at 50 years old, SQL is still one of the most popular programming languages. So, on things like the TOOB index, their IEEE Spectrum index, like most popular programming languages, SQL is just... it's always in the top 10. So, I'm wondering, how do you account for its longevity? I can think of several reasons for that. The first and most important reason is Ted Codd. He got it right. The relational model is simple and powerful and flexible and elegant, and really, that made everything else possible. But second, I think it helped a lot that the early research by both System R and the Ingres project at Cal were published openly. So, there were basically no impediments to commercialization of this technology. That research was given away for free. Third, I think the ANSI standard provided a well-defined language specification and a way for the language to evolve to meet new requirements. And that kept it alive and well as new requirements came along over a period of decades. And fourth, and... this is

really, very important are those high-quality open-source SQL implementations available for free. Well, what's not to like about that? Free stuff is always good for show. Um, excellent. So, looking back on this, do you think that SQL has lived up to what you and Ry envisaged for it back in 1974? Well, that's a good question. In some ways, SQL has been more successful than we ever dreamed it could be, but I'd have to say that the language met the goals that we had defined for ourselves only in part. Remember, R, I thought we would that SQL would be used by what we call casual users who were not computer programmers. Well, it turned out we were wrong about that. The actual users of SQL turned out to be mostly programmers building database applications. Well, I think SQL has made the work of these programmers easier and more productive, so that's a good thing. The casual users, I think, are still out there, but they're not using SQL. They're using Google.

increasingly, I think they're starting to use AI systems like CH GPT. Absolutely, um, that's been a huge change in the last year. It's just, uh, people can have their SQL code written for them quite easily, and so it's made it even more accessible. So, uh, yeah, maybe that'll bring SQL to even more people. Um, all right, is there anything in the world of databases that you are currently excited about? I'm retired now, but, uh, I keep hearing the term NoSQL a lot. Uh, the NoSQL movement, I think, is inspired by web applications that need massively scalable databases, and that's an important requirement. Uh, to get this scalability, these systems usually relax one or more of the constraints of traditional relational databases. Uh, so here are some examples of that. Um, number one, relational databases usually have rigid schemas that say exactly what the tables look like and that are in that system. NoSQL systems sometimes relax this requirement. They might have a partial schema or maybe no schema at all, so they're more

flexible, uh, number two relational databases, uh, have, uh, they're limited to the, uh, relational data model. They have, they're made out of flat homogeneous tables. In each table, all the rows left the same. Well, no systems sometimes relax that requirement and have a different data model. Some of them are just really simple like key-value stores. Others might allow tables to be nested or they might be based on some document format like XML or JSON. They're kind of all over the place, uh, well, third, uh, relational systems usually offer some transactional guarantees like the well-known ACID properties that keep data in a consistent state. Uh, NoSQL systems sometimes relax these guarantees a little bit. They'll often replicate data across many nodes, and they might tolerate what they call eventual consistency, meaning, well, we'll be, we'll be patient, we'll allow the nodes a little while to catch up. So, NoSQL is, uh, is an exciting New Direction. I think it's a broad name for several promising new directions in database research, and, and that's a good

thing um, but sometimes I think scalability is what we want. Uh, but scalability isn't necessarily incompatible with a high-level language. Um, so I've been hearing about um, a new language development called SQL Plus+ that's a clever name, I think. Uh, SQL Plus+ is a backward-compatible extension of SQL that originated at San Diego, uh, by a professor named Yannis Peppa Constantin. And SQL Plus+ has been implemented. It's available in open-source form from the Asteris Data, uh, project at UC Irvine, uh, led by Professor Mike KY. Uh, so you can get it on GitHub, um, and also there are some commercial versions of SQL Plus+ coming out. They're uh, they're being marketed by Couchbase and by Amazon Web Services. Uh, the Amazon version goes by a different name, Particle, but it's basically SQL Plus+. Well, SQL Plus+ uh, it's one of those schema optional languages and for data model, it operates on J collections of JSON documents, which you can also view as nested tables. Uh, the correspondence between a

Json document and nest of tables is the thing that makes SQL++ compatible with earlier versions of SQL that operated on tables. So, if you're interested in this, you can get more information by just Googling SQL Plus+. Okay, that's interesting because the SQL language has been, I mean, there have been some updates but not that many updates to it. And so, having a new language that's sort of similar to SQL and backwards compatible just seems like a pretty good innovation. All right, so, just to wrap up, do you have any final advice for fans of SQL? Well, I look back over my own career, I think of it as a case of being in the right place at the right time. The database revolution has just been unfolding rapidly over the last half-century, and I was really privileged to take a part in it. SQL didn't cause this revolution; it was caused by economics. Hardware was getting faster and cheaper at an exponential rate, and these advances in hardware made

three things possible. The first was a clean, elegant data model like COD's relational model. The second thing was a high-level, non-procedural language, which turned out to be SQL. And the third thing is the optimizing compiler that brought these things together and made them commercially viable. Well, these three items, the data model, the query language, and the optimizing compiler, all support each other, sort of like a three-legged stool. And that's what's made today's database systems possible, I think. So to wrap up, in my career, I've had some lucky breaks. I've been privileged to work with some brilliant people: Ted COD, Ray Boyce, Jim Gray, Pat Selinger, the whole System R team, Mike Stonebraker. I'm in debt to all of these people. It's been a wild ride, and I'm very grateful for the opportunities that have come my way over the years. Wonderful. I mean, it's such a fascinating story and your achievement to just been used by so many millions.

of people so it's a very impressive stuff. Um, all right, uh, thank you for joining me on the show, Don. Oh, thank you, Richie. It's been a pleasure talking to you. Oh. [Music]

#200 50 Years of SQL | Don Chamberlin Computer Scientist and Co-Inventor of SQL

Welcome to DataCamp's official YouTube channel, your premier resource for data science and AI learning! DataCamp is an interactive learning platform aimed at democratizing data science and AI education. Our mission? To empower everyone with the skills to understand, analyze, and interpret data.

Our channel offers educational content, expert talks, and tutorials in data science, AI, machine learning, data visualization, and more. All levels are welcome, from aspiring data scientists to seasoned professionals looking to hone their skills.

Visit our website: https://www.datacamp.com/

Follow us:
Facebook: https://www.facebook.com/datacampinc/
Twitter: https://twitter.com/DataCamp
Instagram: https://www.instagram.com/datacamp
LinkedIn: https://www.linkedin.com/school/datacampinc/

Join us in the data and AI revolution! #DataCamp #DataScience #AI


#200 50 Years of SQL | Don Chamberlin Computer Scientist and Co-Inventor of SQL

#200 50 Years of SQL | Don Chamberlin Computer Scientist and Co-Inventor of SQL

Scripts