왜 SQL을 좋아하지 않습니까? [닫은]
최근 SQL이 끔찍한 언어라고 많이 들었습니다. 태양 아래의 모든 프레임 워크에는 데이터베이스 추상화 계층이 미리 패키지되어있는 것 같습니다.
그러나 필자의 경험에 따르면 SQL은 종종 데이터 입력 및 출력을 관리하는 데 훨씬 쉽고 다재다능하며 프로그래머에게 친숙한 방법입니다. 내가 사용한 모든 추상화 계층은 실질적인 이점이없는 현저하게 제한된 접근법 인 것 같습니다.
SQL이 그렇게 끔찍한 이유는 무엇이며 왜 데이터베이스 추상화 계층이 가치가 있습니까?
이것은 부분적으로 주관적입니다. 그래서 이것은 내 의견입니다.
SQL에는 의사 자연 언어 스타일이 있습니다. 본 발명자들은 영어와 같은 언어를 만들 수 있으며 데이터베이스 쿼리는 매우 간단하다고 믿었다. 끔찍한 실수. 사소한 경우를 제외하고는 SQL을 이해하기가 매우 어렵습니다.
SQL은 선언적입니다. 데이터베이스가 어떻게 해야하는지, 결과로 원하는 것을 말할 수는 없습니다 . 성능에 신경 쓸 필요가 없다면 완벽하고 강력합니다. 따라서 SQL을 읽고 실행 계획을 작성하고 실행 계획에 영향을 주려고 시도하는 SQL을 작성하게되며, 실행 계획을 직접 작성할 수없는 이유가 궁금 합니다 .
선언적 언어의 또 다른 문제는 일부 문제는 명령 방식으로 해결하기 쉽다는 것입니다. 따라서 다른 언어로 작성하거나 (표준 SQL 및 데이터 액세스 계층이 필요함) 저장 프로 시저 등 을 작성하는 등 공급 업체별 언어 확장을 사용 합니다. 그렇게하면 아마도 당신이 본 것 중 최악의 언어 중 하나를 사용하고 있다는 것을 알게 될 것입니다. 왜냐하면 명령형 언어로 사용되도록 설계되지 않았기 때문입니다.
SQL은 매우 오래된 것 입니다. SQL은 표준화되었지만 너무 늦어서 많은 공급 업체에서 이미 언어 확장을 개발했습니다. 따라서 SQL은 수십 가지 방언으로 끝났습니다. 그렇기 때문에 애플리케이션을 이식 할 수없고 DB 추상화 계층을 사용해야하는 이유도 있습니다.
그러나 실현 가능한 대안이 없습니다. 따라서 우리 모두는 앞으로 몇 년 동안 SQL을 사용할 것입니다.
말한 모든 것 외에도 추상화 계층을 소중하게 만들기 위해 기술이 나쁘지 않아도됩니다 .
매우 간단한 스크립트 또는 응용 프로그램을 수행하는 경우 원하는 위치에 코드에서 SQL 호출을 혼합 할 수 있습니다. 그러나 복잡한 시스템을 수행하는 경우 별도의 모듈에서 데이터베이스 호출을 격리하는 것이 좋습니다. 따라서 SQL 코드를 격리하는 것입니다. 코드의 가독성, 유지 보수성 및 테스트 성을 향상시킵니다. 그것은 당신이 모든 높은 수준의 물건 등을 해치지 않고 데이터베이스 모델의 변화에 신속하게 시스템을 적응시킬 수 있습니다.
SQL은 훌륭합니다. 그 위에 추상화 레이어가 더 커집니다!
추상화 계층의 한 가지 점은 SQL 구현이 표준이 약간 모호하고 대부분의 공급 업체가 자체 (비표준) 추가 기능을 추가했기 때문에 SQL 구현이 서로 호환되지 않는 경향이 있다는 사실입니다. 즉, MySQL DB 용으로 작성된 SQL은 Oracle DB와 "유사해야"하더라도 상당히 유사하게 작동하지 않을 수 있습니다.
그러나 SQL이 대부분의 추상화 계층보다 훨씬 낫다는 데 동의합니다. 의도하지 않은 것에 사용되는 것은 SQL의 잘못이 아닙니다.
SQL은 여러 가지 소스에서 나빠집니다.
- 명령적인 언어 이외의 언어에 익숙하지 않은 프로그래머
- 호환되지 않는 많은 SQL 기반 제품을 매일 다루어야하는 컨설턴트
- 시장에 나와있는 관계형 데이터베이스 공급 업체의 문제를 해결하려는 비 관계형 데이터베이스 공급 업체
- 현재 SQL 구현을 불충분 한 것으로 보는 Chris Date와 같은 관계형 데이터베이스 전문가
하나의 DBMS 제품을 고수한다면, 적어도 모델에서 본질적인 확장 성 장벽에 도달 할 때까지 SQL DB가 경쟁 제품보다 다재다능하고 품질이 높다는 데 동의합니다. 그러나 다음 트위터를 실제로 작성하려고합니까, 아니면 회계 데이터를 체계적이고 일관성있게 유지하려고하십니까?
SQL의 비판은 종종 RDBMS에 대한 비판의 표준입니다. RDBMS에 대한 비평가들이 이해하지 못하는 것처럼 보이는 것들은 방대한 종류의 컴퓨팅 문제를 아주 잘 해결하고 우리의 삶을 더 어렵게 만드는 것이 아니라는 것입니다.
SQL 자체를 비판하는 것이 진지한 경우 Tutorial D 및 Dataphor와 같은 노력을 되돌려 놓았습니다.
그렇게 끔찍하지 않습니다. 이 업계에서 새로운 "패러다임"이 나오면 이전의 신뢰할 수있는 기술을 폐기하는 것은 불행한 일입니다. 하루가 끝날 무렵, 이러한 프레임 워크는 아마도 SQL을 사용하여 데이터베이스와 통신 할 가능성이 높습니다. 즉, "표준"추상화 계층이 있다는 것은 개발자가 SQL 코드가 아니라 응용 프로그램 코드에 집중할 수 있음을 의미합니다. 이러한 표준 레이어가 없다면 시스템을 개발할 때마다 가벼운 레이어를 작성하게 될 것입니다. 이는 노력의 낭비입니다.
SQL은 SET 기반 데이터의 관리 및 쿼리를 위해 설계되었습니다. 그것은 종종 더 많은 일을하는 데 사용되며 때로는 가장자리가 좌절감을 유발합니다.
SQL의 실제 사용은 기본 데이터베이스 디자인에 의해 영향을받을 수 있지만 SQL은 문제가되지 않을 수 있습니다. 그러나 디자인은 나쁜 디자인과 관련된 레거시 코드를 던질 때 변경에 더 많은 영향을 미치고 비용이 많이 듭니다 ( 되돌아 가서 "작동"하고 목표를 달성하는 것을 "수정"하는 사람은 없습니다)
목수는 망치로 못을 박고, 톱으로 목재를 보았고, 비행기로 매끄러운 보드를 만들 수 있습니다. 망치와 비행기를 사용하여 "보는"것이 가능하지만 당황 스럽습니다.
나는 그것이 끔찍하다고 말하지 않을 것입니다. 일부 작업에는 적합하지 않습니다. 예를 들어, SQL로 좋은 절차 코드를 작성할 수 없습니다. 한 번은 SQL을 사용하여 집합 조작을 수행해야했습니다. 그것을 알아내는 데 주말 내내 걸렸습니다.
SQL은 관계형 대수를 위해 설계되었습니다.
최근 SQL이 끔찍한 언어라고 많이 들었습니다. 태양 아래의 모든 프레임 워크에는 데이터베이스 추상화 계층이 미리 패키지되어있는 것 같습니다.
이 레이어는 자신의 항목을로 변환합니다 SQL. 대부분의 데이터베이스 공급 업체 SQL는 엔진과 통신 할 수있는 유일한 방법입니다.
그러나 필자의 경험에 따르면 SQL은 종종 데이터 입력 및 출력을 관리하는 데 훨씬 쉽고 다재다능하며 프로그래머에게 친숙한 방법입니다. 내가 사용한 모든 추상화 계층은 실질적인 이점이없는 현저하게 제한된 접근법 인 것 같습니다.
… 내가 방금 설명한 이유.
데이터베이스 레이어는 아무 것도 추가 하지 않고 사용자를 제한 합니다. 쿼리를 더 단순하게 만들지 만 결코 더 효율적이지 않습니다.
정의에 따르면에없는 데이터베이스 계층에는 아무것도 없습니다 SQL.
SQL그렇게 끔찍한 이유는 무엇 이며 왜 데이터베이스 추상화 계층이 가치가 있습니까?
SQL 그러나 좋은 언어이지만, 작동하려면 약간의 두뇌 왜곡이 필요합니다.
이론적으로 SQL는 선언적입니다. 즉, 원하는 것을 선언하고 엔진이 가능한 가장 빠른 방법으로 엔진을 제공합니다.
실제로 올바른 쿼리 (정확한 결과를 반환하는 쿼리)를 구성하는 방법에는 여러 가지가 있습니다.
옵티마이 저는 사전 정의 된 일부 알고리즘 (예 : 여러 개)으로 레고 성을 구축 할 수 있지만 새로운 알고리즘을 만들 수는 없습니다. 여전히 SQL개발자를 지원해야합니다.
그러나 일부 사람들은 옵티마이 저가 "주어진 SQL엔진 구현으로이 쿼리에 사용 가능한 최상의 계획"이 아닌 "최상의 계획"을 생성 할 것으로 기대합니다 .
그리고 우리 모두 알다시피, 컴퓨터 프로그램이 사람들의 기대를 충족시키지 못하면, 그것은 기대가 아닌 비난을받는 프로그램입니다.
그러나 대부분의 경우 쿼리를 재구성하면 실제로 최상의 계획을 만들 수 있습니다. 그러나 불가능한 작업이 있지만 SQL이러한 경우에 대한 새로운 개선 사항 이 점점 더 줄어들고 있습니다.
It would be nice, though, if the vendors provided some low-level access to the functions like "get the index range", "get a row by the rowid" etc., like C compilers let you to embed the assembly right into the language.
I recenty wrote an article on this in my blog:
I'm a huge ORM advocate and I still believe that SQL is very useful, although it's certainly possible to do terrible things with it (just like anything else). .
I look at SQL as a super-efficient language that does not have code re-use or maintainability/refactoring as priorities.
So lightning fast processing is the priority. And that's acceptable. You just have to be aware of the trade-offs, which to me are considerable.
From an aesthetic point of view, as a language I feel that it is lacking some things since it doesn't have OO concepts and so on -- it feels like very old school procedural code to me. But it's far and away the fastest way to do certain things, and that's a powerful niche!
I would say that a database abstraction layer included with a framework is a good thing because it solves two very important problems:
It keeps the code distinct. By putting the SQL into another layer, which is generally very thin and should only be doing the basics of querying and handoff of results (in a standardized way), you keep your application free from the clutter of SQL. It's the same reason web developers (should) put CSS and Javascript in separate files. If you can avoid it, do not mix your languages.
Many programmers are just plain bad at using SQL. For whatever reason, a large number of developers (especially web developers) seem to be very, very bad at using SQL, or RDBMSes in general. They treat the database (and SQL by extension) as the grubby little middleman they have to go through to get to data. This leads to extremely poorly thought out databases with no indexes, tables stacked on top of tables in dubious manners, and very poorly written queries. Or worse, they try to be too general (Expert System, anyone?) and cannot reasonably relate data in any meaningful way.
Unfortunately, sometimes the way that someone tries to solve a problem and tools they use, whether due to ignorance, stubbornness, or some other trait, are in direct opposition with one another, and good luck trying to convince them of this. As such, in addition to just being a good practice, I consider a database abstraction layer to be a sort of safety net, as it not only keeps the SQL out of the poor developer's eyes, but it makes their code significantly easier to refactor, since all the queries are in one place.
SQL is excellent for certain kinds of tasks, especially manipulating and retrieving sets of data.
However, SQL is missing (or only partially implements) several important tools for managing change and complexity:
Encapsulation: SQL's encapsulation mechanisms are coarse. When you write SQL code, you have to know everything about the implementation of your data. This limits the amount of abstraction you can achieve.
Polymorphism: if you want to perform the same operation on different tables, you've got to write the code twice. (One can mitigate this with imaginative use of views.)
Visibility control: there's no standard SQL mechanism for hiding pieces of the code from one another or grouping them into logical units, so every table, procedure, etc. is accessible from every other one, even when it's undesirable.
Modularity and Versioning
Finally, manually coding CRUD operations in SQL (and writing the code to hook it up to the rest of one's application) is repetitive and error-prone.
A modern abstraction layer provides all of those features, and allows us to use SQL where it's most effective while hiding the disruptive, repetitive implementation details. It provides tools to help overcome the object-relational impedance mismatch that complicates data access in object-oriented software development.
SQL is based on Set Theory, while most high level languages are object oriented these days. Object programmers typically like to think in objects, and have to make a mental shift to use Set based tools to store their objects. Generally, it is much more natural (for the OO programmer) to just cut code in the language of their choice and do something like object.save or object.delete in application code instead of having to write sql queries and call the database to achieve the same result.
Of course, sometimes for complex things, SQL is easier to use and more efficient, so it is good to have a handle on both types of technology.
IMO, the problem that I see that people have with SQL has nothing to do with relational design nor the SQL language itself. It has to do with the discipline of modeling the data layer which in many ways is fundamentally different than modeling a business layer or interface. Mistakes in modeling at the presentation layer are generally much easier to correct than at the data layer where you have multiple applications using the database. These problems are the same as those encountered in modeling a service layer in SOA designs where you have to account for current consumers of your service and the input and output contracts.
SQL was designed to interact with relational database models. There are other data models that have existed for some time, but the discipline about designing the data layer properly exists regardless of the theoretical model used and thus, the difficulties that developers typically have with SQL are usually related to attempts to impose a non-relational data model onto a relational database product.
For one thing, they make it trivial to use parameterized queries, protecting you from SQL injection attacks. Using raw SQL, from this perspective, is riskier, that is, easier to get wrong from a security perspective. They also often present an object-oriented perspective on your database, relieving you of having to do this translation.
Heard a lot recently? I hope you're not confusing this with the NoSql movement. As far as i'm aware that is mainly a bunch of people who use NoSql for high scalability web apps and appear to have forgotten that SQL is an effective tool in a non "high scalability web app" scenario.
The abstraction layer business is just about sorting out the difference between Object Oriented code and Table - Set based code such as SQL likes to talk. Usually this results in writing lots of boiler plate and dull transition code between the two. ORM automates this and thus saves time for business objecty people.
For experienced SQL programmer the bad sides are
- Verbosity
- As many have said here, SQL is declarative, which means optimizing is not direct. It's like rallying compared to circuit racing.
- Frameworks that try to address all possible dialects and don't support shortcuts of any of them
- No easy version control.
For others, the reasons are that
- some programmers are bad at SQL. Probably because SQL operates with sets, while programming languages work in object or functional paradigm. Thinking in sets (union, product, intersect) is a matter of habbit that some people don't have.
- some operations aren't self-explanatory: i.e. at first it's not clear that where and having filter different sets.
- there are too many dialects
The primary goal of SQL frameworks is to reduce your typing. They somehow do, but too often only for very simple queries. If you try doing something complex, you have to use strings and type a lot. Frameworks that try to handle everything possible, like SQL Alchemy, become too huge, like another programming language.
[update on 26.06.10] Recently I worked with Django ORM module. This is the only worthy SQL framework I've seen. And this one makes working with stuff a lot. Complex aggregates are a bit harder though.
SQL is not a terrible language, it just doesn't play too well with others sometimes.
If for example if you have a system that wants to represent all entities as objects in some OO language or another, then combining this with SQL without any kind of abstraction layer can become rather cumbersome. There's no easy way to map a complex SQL query onto the OO-world. To ease the tension between those worlds additional layers of abstraction are inserted (an OR-Mapper for example).
SQL is a really good language for data manipulation. From a developer perspective, what I don't like with it is that changing the database don't break your code at compile time... So I use abstraction which add this feature at the price of performance and maybe expressiveness of the SQL language, because in most application you don't need all the stuff SQL has.
The other reason why SQL is hated, is because of relational databases.
The CAP Theorem becomes popular:
What goals might you want from a shared-data system?
- Strong Consistency: all clients see the same view, even in presence of updates
- High Availability: all clients can find some replica of the data, even in the presence of failures
- Partition-tolerance: the system properties hold even when the system is partitioned
The theorem states that you can always have only two of the three CAP properties at the same time
Relational database address Strong Consistency and Partition-Tolerance.
So more and more people realize that relational database is not the silver bullet, and more and more people begin to reject it in favor of high availability, because high availability makes horizontal scaling more easy. Horizontal scaling gain popularity because we have reached the limit of Moore law, so the best way to scale is to add more machine.
If relational database is rejected, SQL is rejected too.
SQL has many flaws, as some other posters here have pointed out. Still, I much prefer to use SQL over many of the tools that people offer as alternatives, because the "simplifications" are often more complicated than the thing they were supposed to simplify.
My theory is that SQL was invented by a bunch of ivory-tower blue-skiers. The whole non-procedural structure. Sounds great: tell me what you want rather than how you want to do it. But in practice, it's often easier to just give the steps. Often this seems like trying to give car maintenance instructions by describing how the car should perform when you're done. Yes, you could say, "I want the car to once again get 30 miles per gallon, and to run with this humming sound like this ... hmmmm ... and, etc" But wouldn't it be easier for everyone to just say, "Replace the spark plugs" ? And even when you do figure out how to express a complex query in non-procedural terms, the database engine often comes up with a very inefficient execution plan to get there. I think SQL would be much improved by the addition of standardized ways to tell it which table to read first and what index to use.
And the handling of nulls drive me crazy! Yes, theoretically it must have sounded great when someone said, "Hey, if null means unknown, then adding an unknown value to a known value should give an unknown value. After all, by definition, we have no idea what the unknown value is." Theoretically, absolutely true. In practice, if we have 10,000 customers and we know exactly how much money 9,999 owe us but there's some question about the amount owed by the last one, and management says, "What are our total accounts receivable?", yes, the mathematically correct answer is "I don't know". But the practical answer is "we calculate $4,327,287.42 but one account is in question so that number isn't exact". I'm sure management would much rather get a close if not certain number than a blank stare. But SQL insists on this mathemcatically pristine approach, so every operation you do, you have to add extra code to check for nulls and handle them special.
All that said, I'd still rather use SQL than some layer built on top of SQL, that just creates another whole set of things I need to learn, and then I have to know that ultimately this will be translated to SQL, and sometimes I can just trust it to do the translation correctly and efficiently, but when things get complex I can't, so now I have to know the extra layer, I still have to know SQL, and I have to know how it's going to translate to I can trick the layer into tricking SQL into doing the right thing. Arggh.
• Every vendor extends the SQL syntax to suit their needs. So unless you're doing fairly simple things, your SQL code is not portable.
• The syntax of SQL is not orthogonal; e.g., the select, insert, update,anddelete statements all have completely different syntactical structure.
I agree with your points, but to answer your question, one thing that makes SQL so "terrible" is the lack of complete standardization of T-SQL between database vendors (Sql Server, Oracle etc.), which makes SQL code unlikely to be completely portable. Database abstraction layers solve this problem, albeit with a performance cost (sometimes a very severe one).
Living with pure SQL can really be a maintenance hell. For me the greatest advantage of ORMs is the ability to safely refactor code without tedious "DB refactoring" procedures. There are good unit testing frameworks and refactoring tools for OO languages, but I yet have to see Resharper's counterpart for SQL, for example.
Still all DALs have SQL behind the scenes, and still you need to know it to understand what's happening to your database, but daily working with good abstraction layer becomes easier.
If you haven't used SQL too much, I think the major problem is the lack of good developer tools.
If you have lots of experience with SQL, you will have, at one point or another, been frustrated by the lack of control over the execution plan. This is an inherent problem in the way SQL was specified to the vendors. I think SQL needs to become a more robust language to truly harness the underlying technology (which is very powerful).
Quick, write me SQL to paginate a dataset that works in MySQL, Oracle, MSSQL, PostgreSQL, and DB2.
Oh, right, standard SQL doesn't define any operators to limit the number of results coming back and which row to start at.
There's no love for SQL because SQL is bad in syntax, semantics and current usage. I'll explain:
- it's syntax is a cobol shrapnel, all the cobol criticism applies here (to a lesser degree, to be fair). Trying to be natural language like without actually attempting to interpret natural language creates arbirtrary syntax (is it DROP TABLE or DROP , UPDATE TABLE , UPDATE or UPDATE IN , DELETE or DELETE FROM ...) and syntactical monstrosities like SELECT (how many pages does it fill?)
- semantics is also deeply flawed, Date explains it in great detail, but it will suffice to note that a three valued boolean logic doesn't really fit a relational algebra where a row can only be or not be part of a table
- having a programming language as the main (and often only) interface to databases proved to be a really bad choice and it created a new category of security flaws
I'd agree with most of the posts here that the debate over the utility of SQL is mostly subjective, but I think it's more subjective in the nature of your business needs.
Declarative languages, as Stefan Steinegger has pointed out, are good for specifying what you want, not how you want to do it. This means that your various implementations of SQL are decent from a high-level perspective : that is, if all you want is to get some data and nothing else matters, you can satisfy yourself with writing relatively simple queries, and choosing the implementation of SQL that is right for you.
If you work on a much "lower" level, and you need to optimize all of that yourself, it's far from ideal. Using a further layer of abstraction can help, but if what you're really trying to do is specify the methods for optimizing queries and so forth, it's a little counter intuitive to add a middleman when trying to optimize.
The biggest problem I have with SQL is like other "standardized" languages, there are very few real standards. I'd almost prefer having to learn a whole new language between Sybase and MySQL so that I don't get the two conventions confused.
While SQL does get the job done it certainly has issues...
- it tries to simultaneously be the high level and the low level abstraction, and that's ... odd. Perhaps it should have been two or more standards at different levels.
- it is a huge failure as a standard. Lots of things go wrong when a standard either stirs in everything, asks too much of implementations, asks too little, or for some reason does not accomplish the partially social goal of motivating vendors and implementors to produce strictly conforming interoperable complete implementations. You certainly cannot say SQL has done any of that. Look at some other standards and note that success or failure of the standard is clearly a factor of the useful cooperation attained:
- RS-232 (Bad, not nearly enough specified, even which pin transmits and which pin receives is optional, sheesh. You can comply but still achieve nothing. Chance of successful interop: really low until the IBM PC made a de-facto useful standard.)
- IEEE 754-1985 Floating Point (Bad, overreach: not a single supercomputer or scientific workstation or RISC microprocessor ever adopted it, although eventually after 20 years we were able to implement it nicely in HW. At least the world eventually grew into it.)
- C89, C99, PCI, USB, Java (Good, whether standard or spec, they succeeded in motivating strict compliance from almost everyone, and that compliance resulted in successful interoperation.)
- it failed to be selected for arguably the most important database in the world. While this is more of a datapoint than a reason, the fact that Google Bigtable is not SQL and not relational is kind of an anti-achievement for SQL.
I don't dislike SQL, but I also don't want to have to write it as part of what I am developing. The DAL is not about speed to market - actually, I have never thought that there would be a DAL implementation that would be faster than direct queries from the code. But the goal of the DAL is to abstract. Abstraction comes at a cost, and here it is that it will take longer to implement.
The benefits are huge, though. Writing native tests around the code, using expressive classes, strongly typed datasets, etc. We use a "DAL" of sorts, which is a pure DDD implementation using Generics in C#. So we have generic repositories, unit of work implementations (code based transactions), and logical separation. We can do things like mock out our datasets with little effort and actually develop ahead of database implementations. There was an upfront cost in building such a framework, but it is very nice that business logic is the star of the show again. We consume data as a resource now, and deal with it in the language we are natively using in the code. An added benefit of this approach is the clear separation it provides. I no longer see a database query in a web page, for example. Yes, that page needs data. Yes, the database is involved. But now, no matter where I am pulling data from, there is one (and only one) place to go into the code and find it. Maybe not a big deal on smaller projects, but when you have hundreds of pages in a site or dozens of windows in a desktop application, you truly can appreciate it.
As a developer, I was hired to implement the requirements of the business using my logical and analytical skills - and our framework implementation allows for me to be more productive now. As a manager, I would rather have my developers using their logical and analytical skills to solve problems than to write SQL. The fact that we can build an entire application that uses the database without having the database until closer to the end of the development cycle is a beautiful thing. It isn't meant as a knock against database professionals. Sometimes a database implementation is more complex than the solution. SQL (and in our case, Views and Stored Procs, specifically) are an abstraction point where code can consume data as a service. In shops where there is a definite separation between the data and development teams, this helps to eliminate sitting in a holding pattern waiting for database implementation and changes. Developers can focus on the problem domain without hovering over a DBA and the DBA can focus on the correct implementation without a developer needing it right now.
Many posts here seem to argue that SQL is bad because it doesn't have "code optimization" features, and that you have no control over execution plans.
What SQL engines are good at is to come up with an execution plan for a written instruction, geared towards the data, the actual contents. If you care to take a look beyond the programming side of things, you will see that there is more to data than bytes being passed between application tiers.
참고URL : https://stackoverflow.com/questions/1643365/why-no-love-for-sql
'IT박스' 카테고리의 다른 글
| 치명적인 오류 : AST 파일이 잘못되었거나 손상되었습니다.-Xcode (0) | 2020.07.22 |
|---|---|
| T-SQL을 사용하여 하위 문자열의 마지막 항목 색인 찾기 (0) | 2020.07.22 |
| Xcode 8 Beta-현재 Swift 구문으로 변환 실패 : 테스트 호스트를 찾을 수 없습니다 (0) | 2020.07.22 |
| APK가 서명되었거나 "디버그 빌드"인지 확인하는 방법 (0) | 2020.07.22 |
| div를 세로로 가운데에 배치하는 방법은 무엇입니까? (0) | 2020.07.22 |