관계형 데이터베이스를 사용하지 않는 좋은 이유는 무엇입니까?

관계형 데이터베이스를 사용하지 않는 좋은 이유는 무엇입니까?

---

대체 데이터 스토리지 도구를 지적하고 오래된 관계형 데이터베이스 대신 사용해야하는 이유를 설명해 주시겠습니까? 제 생각에는 대부분의 응용 프로그램이 SQL의 전체 기능을 거의 사용하지 않으며 SQL 프리 응용 프로그램을 작성하는 방법을 보는 것이 흥미로울 것입니다.

---

파일 시스템의 일반 텍스트 파일

• 작성 및 편집이 매우 간단
• 사용자가 간단한 도구 (예 : 텍스트 편집기, grep 등)로 쉽게 조작 할 수 있습니다.
• 이진 문서의 효율적인 저장

---

디스크의 XML 또는 JSON 파일

• 위와 같지만 구조를 검증 할 수있는 능력이 조금 더 있습니다.

---

스프레드 시트 / CSV 파일

• 비즈니스 사용자가 이해하기 매우 쉬운 모델

---

Subversion (또는 유사한 디스크 기반 버전 제어 시스템)

• 데이터 버전 관리에 대한 매우 좋은 지원

---

버클리 DB (기본적으로 디스크 기반 해시 테이블)

• 개념적으로 매우 간단합니다 (입력되지 않은 키 / 값).
• 꽤 빠른
• 관리 오버 헤드 없음
• 내가 믿는 거래를 지원합니다

---

아마존의 단순 DB

• 내가 생각하는 버클리 DB와 매우 유사하지만 호스팅

---

Google의 App Engine 데이터 스토어

• 호스팅 및 확장 성
• 문서 별 키-값 스토리지 (즉, 유연한 데이터 모델)

---

CouchDB

• 문서 초점
• 반 구조 / 문서 기반 데이터의 간단한 저장

---

모국어 모음 (메모리에 저장되거나 디스크에 직렬화 됨)

• 매우 엄격한 언어 통합

---

맞춤형 (손으로 쓴) 스토리지 엔진

• 필요한 사용 사례에서 잠재적으로 매우 높은 성능

---

나는 그들에 대해 아무것도 알지 못한다고 주장 할 수는 없지만 객체 데이터베이스 시스템 을 살펴볼 수도 있습니다 .

---

Matt Sheppard의 대답은 훌륭하지만 (변신) 스핀들에 대해 생각할 때 다음 요소를 고려할 것입니다.

1. 구조 : 분명히 조각으로 나뉘어 있습니까, 아니면 절충하고 있습니까?
2. 사용법 : 데이터는 어떻게 분석 / 검색 / 그로 킹됩니까?
3. 수명 : 데이터가 얼마나 오래 유용합니까?
4. 크기 : 얼마나 많은 데이터가 있습니까?

RDBMS에 비해 CSV 파일의 특별한 장점 중 하나는 압축하고 쉽게 다른 시스템으로 이동할 수 있다는 것입니다. 우리는 큰 데이터 전송을 수행하며 모든 것이 간단하여 하나의 큰 CSV 파일 만 사용하고 rsync와 같은 도구를 사용하여 쉽게 스크립트를 작성할 수 있습니다. 큰 CSV 파일의 반복을 줄이려면 YAML 과 같은 것을 사용할 수 있습니다 . 중요한 관계 요구 사항이 없으면 JSON 또는 XML과 같은 것을 저장할지 확실하지 않습니다.

언급되지 않은 대안으로는 MapReduce의 오픈 소스 구현 인 Hadoop을 할인하지 마십시오 . 분석해야하는 느슨하게 구조화 된 데이터의 톤이 있고 데이터 처리를 처리하기 위해 10 대의 기계를 추가 할 수있는 시나리오를 원할 경우이 방법이 효과적입니다.

예를 들어, 나는 약 20 대의 컴퓨터에 걸쳐 기록 된 서로 다른 기능의 모든 타이밍 번호 인 성능을 분석하기 시작했습니다. RDBMS에서 모든 것을 고수하려고 시도한 후에는 데이터를 집계 한 후 다시 쿼리 할 필요가 없다는 것을 깨달았습니다. 그리고 그것은 나에게 집계 된 형식에서만 유용합니다. 따라서 로그 파일을 압축하여 압축 한 다음 집계 된 데이터를 DB에 그대로 둡니다.

참고 "큰"크기로 생각하는 데 더 익숙합니다.

---

파일 시스템의 prety는 바이너리 데이터를 저장하는 데 편리하며 관계형 데이터베이스에서는 결코 훌륭하게 작동하지 않습니다.

---

Prevayler를 사용해보십시오. http://www.prevayler.org/wiki/ Prevayler는 RDBMS의 대안입니다. 이 사이트에는 더 많은 정보가 있습니다.

---

ACID 가 필요하지 않은 경우 RDBMS의 오버 헤드가 필요하지 않을 수 있습니다. 따라서 먼저 필요한지 결정하십시오. 여기에 제공된 대부분의 비 RDBMS 답변 은 ACID를 제공 하지 않습니다 .

---

맞춤형 (손으로 쓴) 스토리지 엔진 / 필요한 사용 사례에서 잠재적으로 매우 높은 성능

http://www.hdfgroup.org/

막대한 데이터 세트가있는 경우 직접 롤링하는 대신 계층 데이터 형식 인 HDF를 사용할 수 있습니다.

http://en.wikipedia.org/wiki/Hierarchical_Data_Format :

HDF는 다차원 배열, 래스터 이미지 및 테이블을 포함하여 여러 가지 다른 데이터 모델을 지원합니다.

파일 시스템과 같이 계층 적이지만 데이터는 하나의 마법 이진 파일에 저장됩니다.

HDF5는 매우 크고 복잡한 데이터 수집을 관리 할 수있는 제품군입니다.

페타 바이트의 NASA / JPL 원격 감지 데이터를 생각하십시오.

---

G'day,

내가 생각할 수있는 한 가지 사례는 모델링하는 데이터를 관계형 데이터베이스에 쉽게 표현할 수없는 경우입니다.

일단 그러한 예는 이동 전화 사업자들이 이동 전화 네트워크를위한 기지국을 모니터링 및 제어하기 위해 사용하는 데이터베이스이다.

나는 거의 모든 경우에, OO DB 가 상업적 제품이거나 객체의 계층 구조를 허용하는 자체 롤링 시스템으로 사용된다.

I've worked on a 3G monitoring application for a large company who will remain nameless, but whose logo is a red wine stain (-: , and they used such an OO DB to keep track of all the various attributes for individual cells within the network.

Interrogation of such DBs is done using proprietary techniques that are, usually, completely free from SQL.

HTH.

cheers,

Rob

---

Object databases are not relational databases. They can be really handy if you just want to stuff some objects in a database. They also support versioning and modify classes for objects that already exist in the database. db4o is the first one that comes to mind.

---

In some cases (financial market data and process control for example) you might need to use a real-time database rather than a RDBMS. See wiki link

---

There was a RAD tool called JADE written a few years ago that has a built-in OODBMS. Earlier incarnations of the DB engine also supported Digitalk Smalltalk. If you want to sample application building using a non-RDBMS paradigm this might be a start.

Other OODBMS products include Objectivity, GemStone (You will need to get VisualWorks Smalltalk to run the Smalltalk version but there is also a java version). There were also some open-source research projects in this space - EXODUS and its descendent SHORE come to mind.

Sadly, the concept seemed to die a death, probably due to the lack of a clearly visible standard and relatively poor ad-hoc query capability relative to SQL-based RDMBS systems.

An OODBMS is most suitable for applications with core data structures that are best represented as a graph of interconnected nodes. I used to say that the quintessential OODBMS application was a Multi-User Dungeon (MUD) where rooms would contain players' avatars and other objects.

---

You can go a long way just using files stored in the file system. RDBMSs are getting better at handling blobs, but this can be a natural way to handle image data and the like, particularly if the queries are simple (enumerating and selecting individual items.)

Other things that don't fit very well in a RDBMS are hierarchical data structures and I'm guessing geospatial data and 3D models aren't that easy to work with either.

Services like Amazon S3 provide simpler storage models (key->value) that don't support SQL. Scalability is the key there.

Excel files can be useful too, particularly if users need to be able to manipulate the data in a familiar environment and building a full application to do that isn't feasible.

---

There are a large number of ways to store data - even "relational databse" covers a range of alternatives from a simple library of code that manipulates a local file (or files) as if it were a relational database on a single user basis, through file based systems than can handle multiple-users to a generous selection of serious "server" based systems.

We use XML files a lot - you get well structured data, nice tools for querying same the ability to do edits if appropriate, something that's human readable and you don't then have to worry about the db engine working (or the workings of the db engine). This works well for stuff that's essentially read only (in our case more often than not generated from a db elsewhere) and also for single user systems where you can just load the data in and save it out as required - but you're creating opportunities for problems if you want multi-user editing - at least of a single file.

For us that's about it - we're either going to use something that will do SQL (MS offer a set of tools that run from a .DLL to do single user stuff all the way through to enterprise server and they all speak the same SQL (with limitations at the lower end)) or we're going to use XML as a format because (for us) the verbosity is seldom an issue.

We don't currently have to manipulate binary data in our apps so that question doesn't arise.

Murph

---

One might want to consider the use of an LDAP server in the place of a traditional SQL database if the application data is heavily key/value oriented and hierarchical in nature.

---

BTree files are often much faster than relational databases. SQLite contains within it a BTree library which is in the public domain (as in genuinely 'public domain', not using the term loosely).

Frankly though, if I wanted a multi-user system I would need a lot of persuading not to use a decent server relational database.

---

Full-text databases, which can be queried with proximity operators such as "within 10 words of," etc.

Relational databases are an ideal business tool for many purposes - easy enough to understand and design, fast enough, adequate even when they aren't designed and optimized by a genius who could "use the full power," etc.

But some business purposes require full-text indexing, which relational engines either don't provide or tack on as an afterthought. In particular, the legal and medical fields have large swaths of unstructured text to store and wade through.

---

Also: * Embedded scenarios - Where usually it is required to use something smaller then a full fledged RDBMS. Db4o is an ODB that can be easily used in such case. * Rapid or proof-of-concept development - where you wish to focus on the business and not worry about persistence layer

---

CAP theorem explains it succinctly. SQL mainly provides "Strong Consistency: all clients see the same view, even in presence of updates".

---

K.I.S.S: Keep It Small and Simple

---

I would offer RDBMS :) If you do not wont to have troubles with set up/administration go for SQLite. Built in RDBMS with full SQL support. It even allows you to store any type of data in any column.

Main advantage against for example log file: If you have huge one, how are you going to search in it? With SQL engine you just create index and speed up operation dramatically.

About full text search: SQLite has modules for full text search too..

Just enjoy nice standard interface to your data :)

---

One good reason not to use a relational database would be when you have a massive data set and want to do massively parallel and distributed processing on the data. The Google web index would be a perfect example of such a case.

Hadoop also has an implementation of the Google File System called the Hadoop Distributed File System.

---

I would strongly recommend Lua as an alternative to SQLite-kind of data storage.

Because:

• The language was designed as a data description language to begin with
• The syntax is human readable (XML is not)
• One can compile Lua chunks to binary, for added performance

This is the "native language collection" option of the accepted answer. If you're using C/C++ as the application level, it is perfectly reasonable to throw in the Lua engine (100kB of binary) just for the sake of reading configs/data or writing them out.

참고URL : https://stackoverflow.com/questions/37823/good-reasons-not-to-use-a-relational-database