SQL (언어)의 좋은 대안은 무엇입니까? [닫은]
나는 때때로 SQL이 얼마나 짜증나고 좋은 언어가 아닌지에 대한 이야기를 듣지만 그 대안에 대해서는별로 듣지 못했습니다. 그렇다면 동일한 목적 (데이터베이스 액세스)을 제공하는 다른 좋은 언어가 있으며 SQL보다 나은 점은 무엇입니까? 이 대체 언어를 사용하는 좋은 데이터베이스가 있습니까?
편집 : 나는 SQL에 익숙하고 항상 사용합니다. 나는 그것에 문제가 없으며, 존재할 수있는 대안에 관심이 있고 사람들이 왜 그들을 더 좋아하는지에 관심이 있습니다.
또한 다른 종류의 데이터베이스 (NoSQL 운동)를 찾는 것이 아니라 데이터베이스에 액세스하는 다른 방법을 찾고 있습니다.
나는 SQL의 구문이 자동 생성의 관점과 구문 분석의 관점 모두에서 작업하기 어렵다는 데 동의하며, 우리가 요구하는 SQL을 설계한다면 오늘날 작성할 언어 스타일이 아닙니다. 오늘 그것에. 오늘 우리가 언어를 디자인했다면 그렇게 많은 다양한 키워드를 찾을 수 없을 것이라고 생각합니다. 조인 구문이 다를 수 있고, 함수 GROUP_CONCAT의 동작을 제어하기 위해 괄호 중간에 더 많은 키워드를 붙이는 것보다 더 규칙적인 구문을 가질 것이라고 생각합니다. ... 오늘 우리가 언어를 재 설계하면 완화되기를 원하거나 기대하는 SQL의 불일치 및 중복 목록을 직접 작성하십시오.
관계형 데이터베이스 (예 : 프로토콜로서의 SQL)와 대화하기위한 SQL에 대한 대안은 없지만 응용 프로그램에서 SQL을 작성하는 데는 많은 대안이 있습니다. 이러한 대안은 관계형 데이터베이스 작업을위한 프런트 엔드 형태로 구현되었습니다. 프런트 엔드의 몇 가지 예는 다음과 같습니다.
- SchemeQL 및 CLSQL 은 Lisp 유산으로 인해 가장 유연하지만 다른 프런트 엔드보다 SQL과 훨씬 비슷해 보입니다.
- LINQ (.Net)
- ScalaQL 및 ScalaQuery (Scala)
- SqlStatement , ActiveRecord 및 기타 많은 Ruby
- HaskellDB
- ... 목록은 다른 많은 언어에 대해서도 계속됩니다.
오늘의 기본 주제는 SQL을 하나의 새로운 쿼리 언어로 대체하는 대신, 일상적인 프로그래밍 언어로 SQL을 숨기고 SQL 을 관계형과 대화하기위한 프로토콜 로 처리하는 언어 별 프런트 엔드를 만드는 것입니다. 데이터베이스.
Hibernate Query Language 가 아마도 가장 일반적입니다. Hibernate의 장점은 객체가 관계형 데이터베이스에 매우 쉽게 (거의 자동으로) 매핑되고 개발자가 데이터베이스 설계에 많은 시간을 할애 할 필요가 없다는 것입니다. 자세한 정보 는 Hibernate 웹 사이트 를 확인하십시오 . 나는 다른 사람들이 다른 흥미로운 쿼리 언어를 사용하게 될 것이라고 확신합니다.
물론 많은 NoSQL 관련 항목이 있지만 특별히 관심이 없다고 언급했습니다.
"저는 가끔 SQL이 얼마나 형편없고 좋은 언어가 아니라는 얘기를 듣습니다."
SQL은 30 년이 넘었습니다. "어떤 기능이 어떤 것을 '좋은'언어로 만들고 어떤 기능이 '나쁜'언어로 만드는지"에 대한 통찰력은 SQL 자체보다 더 빠르게 진화했습니다.
또한 SQL은 "관계형이되기 위해 필요한 것"의 현재 표준을 따르는 언어가 아니므로 SQL은 부팅 할 관계형 언어가 아닙니다.
"그러나 나는 그것에 대한 대안에 대해 많이 듣지 못했습니다."
잘못된 곳 (즉, 상용 DBMS 산업에만 해당)에서만 들으려고 할 가능성에 대해 생각해 보시길 바랍니다.
"그러면 동일한 목적 (데이터베이스 액세스)을 제공하는 다른 좋은 언어가 있으며 SQL보다 나은 점은 무엇입니까?"
Date & Darwen은 최신 데이터 조작 언어가 준수해야하는 기능을 "Third Manifesto"에서 설명합니다. 가장 최근 버전은 "Databases, Types & the Relational Model"에 나와 있습니다.
"이 대체 언어를 사용하는 좋은 데이터베이스가 있습니까?"
"좋다"라는 말이 "산업 강도"와 같은 의미라면 아니오. 사용 가능한 가장 가까운 것은 아마도 Dataphor 일 것입니다.
Rel 프로젝트는 "데이터베이스, 유형 및 관계형 모델"에 정의 된 Tutorial D 언어에 대한 구현을 제공하지만 현재 Rel의 주요 목표는 본질적으로 교육적인 것입니다.
내 SIRA_PRISE 프로젝트는 "진정한 관계형"데이터 관리에 대한 구현을 제공하지만 "언어의 구현"이라는 레이블도 지정하는 것을 주저합니다.
물론 일부가 제안한 것처럼 비 관계형 데이터를 살펴볼 수도 있지만 저는 개인적으로 비 관계형 데이터 관리를 수십 년의 기술적 회귀라고 일축합니다. 고려할 가치가 없습니다.
아, 그리고 데이터베이스를 관리하는 데 사용되는 소프트웨어 시스템은 "데이터베이스"가 아니라 "데이터베이스 관리 시스템", 줄여서 "DBMS"입니다. 사진이 카메라와 같지 않은 것처럼 카메라에 대해 논의하고 혼동을 피하려면 "사진"대신 "카메라"라는 적절한 단어를 사용해야합니다.
아마도 당신은 C. Date와 그의 친구들이 기존의 관계형 데이터베이스와 SQL에 반대하는 비판을 생각하고있을 것입니다. 그들은 시스템과 언어가 100 % 관계형이 아니며 그래야한다고 말합니다. 여기서 진짜 문제는 보이지 않습니다. 내가 볼 수있는 한, 당신이 원한다면 SQL을 사용하는 방식을 훈육함으로써 100 % 관계형 시스템을 가질 수 있습니다.
제가 개인적으로 계속 부딪 치는 것은 SQL이 이론적 기반 인 관계형 대수에서 물려받은 표현력이 부족하다는 것입니다. 한 가지 문제는 날짜, 타임 스탬프 등으로 표시된 데이터로 작업 할 때 발생하는 도메인 순서 사용에 대한 지원 부족입니다. 한 번은 타임 스탬프가 가득한 데이터베이스에서 일반 SQL로보고 응용 프로그램을 완전히 수행하려고 시도했지만 실행 가능하지 않았습니다. 다른 하나는 경로 순회에 대한 지원이 부족하다는 것입니다. 대부분의 데이터는 경로를 순회해야하는 방향성 그래프처럼 보이지만 SQL은이를 수행 할 수 없습니다. ( "전 이적 폐쇄"가 부족합니다. SQL-1999는 "재귀 적 하위 쿼리"로 수행 할 수 있지만 아직 실제로 사용하지는 않았습니다. SQL에 대처할 수있는 다양한 해킹도 있지만보기 흉합니다.) 이러한 문제는 다음과 같습니다. 그건 그렇고, Date의 일부 저술에서도 논의되었습니다.
최근 전 이적 폐쇄 문제를 잘 해결하는 것처럼 보이는 .QL 을 지적 했지만 주문 된 도메인의 문제를 해결할 수 있는지 여부는 모르겠습니다.
LINQ to SQL 살펴보기 ...
몇 달 전에 그것을 시도했고 결코 뒤돌아 보지 않았습니다 ....
직접적인 대답 : 나는 거기에 심각한 경쟁자가 없다고 생각합니다. DBase와 그 모방 자 (Foxpro, Codebase 등)는 한동안 경쟁자 였지만 기본적으로 데이터베이스 쿼리 언어 전쟁에서 졌다고 생각합니다. Progress 및 Paradox와 같은 고유 한 쿼리 언어를 가진 다른 많은 데이터베이스 제품이 있습니다. 예를 들어 Progress 및 Paradox와 같은 이름을 기억하지 못하는 다른 여러 제품과 확실히 들어 본 적이없는 더 많은 제품이 있습니다. 그러나 나는 다른 경쟁자가 시장에서 사소한 점유율을 얻지 못했다고 생각합니다.
As simple proof that there is a difference between a database format and a query language, the last version of DBase I used -- many years ago now -- offerred both the "traditional" DBase query language and SQL, both of which could be used to access the same data.
Side ramble: I wouldn't say that SQL sucks, but it has many flaws. With the benefit of the years of experience and hindsight we now have, I'm sure one could design a better query language. But creating a better query language, and convincing people to use it, are two very different things. Would it be enough better to convince people that it was worth the trouble of learning. People have invested many years of their lives learning to use SQL effectively. Even if your new language is easier to use, there would surely be a learning curve. And how would you migrate your existing systems from SQL to the new language? Etc. It can be done, of course, just like C++, C#, and Java have largely overthrown COBOL and FORTRAN. But it takes a combination of technical superiority and good marketing to pull it off.
Still, I get a chuckle out of people who rush forward to defend SQL anytime someone criticizes it, who insist that any problem you have with SQL must be your own ineptitude in using it and not any fault of SQL, that you must just not have reached the higher plane of thingking necessary to comprehend its perfection, etc. Calm down, take a deep breath: We are insulting a computer language, not your mother.
Back in the 1980's, ObjectStore provided transparent object access. It was kind of like an RDBMS plus an ORM, except without all those extra leaky abstraction layers: it stored objects directly in the database.
So this alternative was really "no language at all", or perhaps "the language you're already using". You'd write C++ code and create or traverse objects as if they were native objects, and the database took care of everything as needed. Kind of like ActiveRecord but it actually worked as well as the ActiveRecord marketing blitzes claim. :-)
(Of course, it didn't have Oracle's marketing muscle, and it didn't have MySQL's zero-cost, so everybody ignored it. And now we try to replicate that with RDBMSs and ORMs, and some people try to argue that tables actually make sense for storing objects, and that writing giant XML file to tell your computer how to map objects to tables is somehow a reasonable solution.)
The general movement these days is NoSQL; generally these technologies are:
- Distributed "hashtables" that store data as key/value pairs
- Document-oriented databases
Personally I think there is nothing wrong with SQL as long as it fits your needs. SQL is expressive and great for working with structured data.
I think you might be interested in looking at Dataphor, which is an open-source relational development environment with its own database server (which speaks D), and the ability to derive user interfaces from its query language.
Also, it appears Ingres still supports QUEL, and it's open source.
There are many implementations of SQL (SQL Server, mysql, Oracle, etc.), but there is no other language that serves the same purpose in the sense of being a general purpose language designed for relational data storage and retrieval.
There are object databases such as db4o, and there are similar so-called noSQL databases that refer to just about any data storage mechanism that doesn't rely on SQL, but most commonly open-source products like Cassandra based loosely on Google's Bigtable concept.
There are also a number of special-purpose database products like CDF, but you probably don't need to worry about those - if you need one, you'll know.
None of these are equivalent to SQL.
That doesn't mean they're "better" or "worse" - they're just not the same. Dennis Forbes wrote a great post recently breaking down a number of the strange claims surfacing against SQL. He maintains (and I agree) that these complaints originate largely from people and shops who have either picked the wrong tool for the job in the first place, or aren't using their SQL DBMS properly (I'm not even surprised anymore when I see another SQL database where every column is a varchar(50) and there's not a single index or key, anywhere).
If you are implementing yet another social networking site and aren't too concerned with ACID principles, by all means start looking into products such as db4o. If you are developing a mission-critical business system, however, I highly highly recommend that you think twice before joining the "SQL sucks" chorus. Do the research first, find out what features the various products can and cannot support.
Edit - I was busy writing my answer and didn't get the question update from a few minutes. Having said that, SQL is essentially inseparable from the DBMS itself. If you run a SQL database product, then you access it with SQL, period.
Perhaps you are looking for abstractions over the syntax; Linq to SQL, Entity Framework, Hibernate/NHibernate, SubSonic, and a host of other ORM tools all provide their own SQL-like syntax that is not quite SQL. All of these "compile down" to SQL. If you run SQL Server, then you can also write CLR Functions/Procedures/Triggers, which allows you to write code in any .NET language that will run inside the database; however, this isn't really a substitute for SQL, more of an extension to it.
I'm not aware of any full "language" that you can layer on top of a SQL database; short of switching to a different database product, you're eventually going to see SQL on the pipe.
SQL works fine for the domain for which it was designed — interrelated tables of data. This is generally found in traditional business data processing. SQL doesn't work that well when trying to persist a complex network of objects.
If your needs are to store and process relatively traditional data, use some SQL-based DBMS.
In response to your edit:
If you're looking for alternatives to the SQL DML for retrieving data from relational data stores, I've never heard of any serious alternative to SQL.
The knocks SQL gets are not, I think, so much against the language as opposed to the underlying data storage principles on which the language is based. People often confuse the language SQL with the relational data model on which RDBMSes are built.
Relational Databases are not the only kind of databases around. I should say a word about Object-Databases as I havn't seen it in responses from others. I had some experience with the Zope python framework that use ZODB for objects persistency instead of RDBMS (well, it's theoretically possible to replace ZODB by another database within zope but the last time I checked I didn't succeed to have it working, so can't be positive about that).
The ZODB mindset is really different, more like object programming that would happen to be persistent.
ORM can be seen as a kind of language
In a way I believe the Object-database model is what ORM are about : accessing persistent data through your usual object model. It's a kind of language and it's gaining some market share, but for now we don't see it as a language but as an abstraction layer. However I believe it would be much more efficient to use an ORM over an Object-database than over SQL (in other words performance of ORMs I happened to use using some SQL database as base layers sucked).
SQL is de-facto.
Frameworks that try to shield developers from it have eventually created their own specific language (Hibernate HQL comes to mind).
SQL solves a problem fairly well. It is no more difficult to learn than a high level programming language. If you already know a functional language then it is a breeze to grasp SQL.
Considering the leading database vendors providing state of the art databases (Oracle and SQL Server) support SQL and have invested years into optimization engines, etc. and all leading data modelling software and change management software deals in SQL, I'd say it is the safest bet.
Also, there is more to a database than just queries. There is scalability, backup and recovery, data mining. The big vendors support a lot of things that even the new "cache" engines don't even consider.
Problems with SQL have motivated me to cook up a draft query language called SMEQL over at the Portland Pattern Repository wiki. Comments Welcome. It borrows ideas from functional programming and IBM's experimental Business System 12 language. (I originally called it TQL, but found later that name was taken.)
Within the .NET world, while it still has a SQL-esque feel to it, LINQ-to-SQL will allow you to have a good mix of SQL and in-memory .NET processing of your data. It also simplifies a lot of the lower-level data plumbing that nobody really wants to do.
If you want to see a database type of a completely different mindset, take a look at CouchDB. "Better" is obviously a relative requirement and this sort of non-relation database is "Better" but only in certain scenarios.
SQL the language is very powerful, and relational database management systems have been and still are a huge success. But there is a class of application that requires very high scalability and availability, but not necessarily a high degree of data consistency (eventual consistency is what matters). A variety of systems get better performance and scaling than an RDBMS by relaxing the need for full ACID compliant transactions. These have been named "NoSQL", but as others point out, this is a misnomer: that perhaps they should be called NoACID databases.
Michael Stonebraker covers this in The "NoSQL" Discussion has Nothing to Do With SQL.
참고URL : https://stackoverflow.com/questions/2497227/what-are-good-alternatives-to-sql-the-language
'programing' 카테고리의 다른 글
| http 범위 요청 세션 샘플 (0) | 2020.09.12 |
|---|---|
| 공유 _ptr 다운 캐스팅 (0) | 2020.09.12 |
| Python에서 현재 시간을 읽을 수있는 형식으로 표시하는 방법 (0) | 2020.09.12 |
| 숨겨진 파일을 grep하려면 어떻게해야합니까? (0) | 2020.09.12 |
| bash 명령에 여러 환경 변수를 설정하는 방법 (0) | 2020.09.12 |