close
프로필 배경
프로필 로고

DK308C

TIL · 2023. 9. 7. fullscreen 넓게보기

[SeSAC] September 7, 2023

목차

뻘이지만 9월이 오면 이 노래를 항상 들어 줘야 한다

9월이 끝날 때까지!!

 

 

✔︎ 오늘의 정리

  • DB / DBMS
  • RDBMS 구조
    • 정규화
      • PK / FK / UK
    • Schema / Column / Record
  • Transaction
    • ACID(pass)
  • Migration

 

DB / DBMS / UserDefault

  • DB?
    • Database의 약자로, 데이터를 저장한 파일들의 집합체를 말한다. 방대한 양의 수집된 데이터를 효율적으로 저장한 것.
    • DB가 어떤 식으로 구성되어 있는지, 어떻게 정렬되어 있는지에 따라서 데이터를 찾고, 받아오는 시간이 달라지기 때문에 관리가 필요하다.
  • DBMS?
    • DataBase Management System의 약자로, 데이터베이스 자체를 관리하기 위한 소프트웨어를 말한다.
    • 대부분의 DB들이 DBMS를 통해 만들어지고 운영되기 때문에 의미를 혼용해서 사용하기도 한다.
    • 계층형, 관계형, 객체관계형 등 다양하다.
  • UserDefault VS DB
    • UserDefault는 배열의 형태로 저장되며, 데이터베이스는 여러 형태로 저장된다. (realm의 경우에는 테이블 형태로 저장!!)
    • UserDefault는 간단한 데이터를 저장할 때 편하다. 하지만, 배열의 형태로 저장되기 때문에 그 수가 기하급수적으로 많아진다면 데이터를 필터링하여 가져올 때 오랜 시간이 걸린다.
    • 반면, 데이터베이스는 데이터의 크기가 커질 경우에 빛을 발한다. 자체적으로 제공해주는 필터 기능도 있고, table 내의 값을 기준으로 비교적 빠른 검색이 가능하다.

 

 

 

RDBMS의 구조

  • DBMS 중 가장 많이 사용되는 것이 관계형 데이터베이스인 RDBMS이다.
    • RDBMS는 관계형 데이터베이스를 생성, 수정, 관리할 수 있는 소프트웨어로 명확한 데이터 구조를 가졌다.
      • 테이블 - 컬럼 형태로 데이터를 저장할 수 있으며, 테이블과 테이블간의 연간관계를 이용하여 필요한 정보를 구현한다.
      • 따라서, 수평적으로 확장이 어려워 수직정 확장을 하지만 데이터가 과도할 경 한계가 있을 수 있다. 
      • 비용과 시스템의 복잡성이 있을 수 있다.
        • 시스템이 복잡해질수록 query문이 복잡해지고 성능 저하가 일어날 수 있다.
      • 중복 데이터 저장 방지를 위해 정규화를 하여 데이터의 독립성이 높다.
        • 이때, 정규화란 같은 데이터들을 어떻게 효율적으로 다룰 수 있을지에 대한 방법으로 테이블을 분할해 생성하며 정규화를 할 수 있다.
  • RDBMS는 흔히 말하는 엑셀 시트라고 보면 된다. 

etc-image-0

  • Schema
  • Table
    • 엑셀 시트 하나당 Table이라고 하며, row와 column으로 이루어져 있다.
    • 일관된 특징을 가지며, 중복되지 않는 데이터를 저장하기 위한 데이터의 모임이라고 보면 된다.
      • Column(Attribute)
        • 테이블을 구성하는 정보 중 세로로 묶은 데이터를 말하며, 보통 특징별로, 데이터타입별로 묶인다.
      • Record(row)
        • 테이블을 구성하는 정보 중 가로로 묶은 데이터를 말하며, 보통 한 객체에 대한 정보를 담고 있다.
  • PK / UK / FK
    • FK라고 하니 왠지 욕 같지만... 암튼!!
    • PK(PrimaryKey)
      • 테이블에 대한 고유한 식별값을 말하며, 이 키는 중복되어서도 안 되고 nil값이 되어서도 안 된다.
      • 레코드 검색의 기준이기 때문에 검색을 위해 내부적으로 인덱싱을 한다.
      • 사원번호나 주민번호, 등록번호 같이 남들과 일치될 수 없는 나만의 정보를 primaryKey라고 한다!!
    • FK(ForeignKey)
      • 어떤 테이블의 기본 키가 다른 테이블의 컬럼으로 들어가 있는 경우를 말한다.
      • 즉, 다른 테이블의 PK를 말하며 외부 식별자 키로 테이블간의 관계를 나타내어 준다.
      • FK로 다른 테이블의 PK값을 사용할 경우 참조한다고 말하며 두 테이블간의 종속이 필요하다면 서로 참조할 수도 있다.
    • UK(UniqueKey)
      • PrimaryKey는 아니지만 값의 중복을 허용하기 위해 unique 제약을 걸어놓은 것을 말한다.
      • PK와 달리 비어 있을 수 있으며, 그냥 고유하기만 한 값이지 중복이 가능하당.

 

 

 

 

Transaction

트랜잭션은 데이터베이스의 상태를 변환시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위 또는 한꺼번에 수행되어야 할 일련의 연산을 말한다.

 

머..... 먼소리고

 

이어서 완전성을 보장해야 한다느니 뭐 그런 이야기도 나오는데 그건 둘째치고 트랜잭션이 뭔지부터 알아보자.

 

트랜잭션은 우리가 흔히 데이터를 다룰 때 사용하는 CRUD(CREATE / READ / UPDATE / DELETE)를 수행하여 데이터베이스의 상태를 변화시키는 작업을 말한다.

작업 수행의 논리적인 단위를 말하며, DB가 느리다 / 빠르다의 기준은 transaction이 1초에 얼마나 많은 작업을 수행하느냐를 말한다.

 

RDBMS에서 컬럼을 새로 만들 수도 있고(CREATE) 새로운 객체를 읽어올 수도(READ), 원래 있던 객체의 값을 변경할 수도(UPDATE), 잇던 객체를 삭제할 수도(DELETE) 있을 것이다.

 

글쿠나. 근데 작업의 완전성은 왜 나오는 걸까?

 

왜냐면 항상 데이터가 완벽하게 처리될 수 없기 때문이다. 만약 내가 작업을 세 개 하려고 한다고 하자. 근데 통신 오류 때문에 세 개 중에 하나의 작업만 실행됐다. 이때, DB가 일부 업데이트된다면? 추후에 데이터를 변경할 때 이상하게 변경될 것이다.

 

완전성은 논리적인 작업을 처리할 때 상태를 두 가지 상태로 본다. 완벽하게 처리할 경우와 처리하지 못할 경우로! 완벽하게 처리할 경우에는 처리됐어~~!! 하고 넘기고, 처리하지 못할 경우에는 원 상태로 복구하여 작업의 일부만 적용되지 않도록 만들어 주는 것이다.

그럼 사용자의 입장에서는 작업의 단위를 논리적으로 이해할 수 있고, 시스템 입장에서도 데이터를 접근 또는 변경하는 프로그램의 단위가 명확해진다.

 

 

암튼! DB에 뭔가를 넣을 경우에 try 코드에 담아야 하는 이유가 이 완전성 때문이다.

하나하나 시도한다면 그건 어느 하나만 실행됐을 때 변수를 막을 수 없으니까~~~!!!!

예시를 보장.

 

        // tableSheet 찾았으니 그 시트에 내용을 좀 써주
        realm.add(task) // error!!!!!
        
        try! realm.write {
            realm.add(task)
            print("saved!")
        }

etc-image-1
렘을 이용하여 추가는 햇는데 이상하게 추가했을 때 나타나는 오류이다.

Can only add, remove, or create objects in a Realm in a write transaction ... ...

^____^

 

Transaction이 안전하게 수행되어야 한다는 것을 보장하기 위한 성질을 가리키는 약어로 ACID가 있는데, Atomicity, Consistency, Isolation, Durability이다. 얘네는 나중에 글로 정리할 때 해보겟다~~ ^^

 

 

 

 

Migration

Migration은 DB에만 적용되는 개념이 아니고, 하드웨어, 소프트웨어, 네트워크 등 넓은 범위에서 사용되고 있는 개념으로, 현재 운영 환경으로부터 다른 운영 환경으로 옮기는 작업을 말한다.

여기서는 DB를 이야기하고 있으니까!! 스키마 버전을 관리하기 위해서 사용된다.

 

근데 스키마가 모엿더라?

스키마는 데이터베이스 전체 또는 일부의 논리적인 구조를 표현한 것으로 데이터베이스가 어떻게 구성되어 있는지를 나타내는 친구를 말한다.

 

오잉 그럼 스키마 버전은 먼데?

 

우리가 만약에 컬럼이나 로우를 추가 / 삭제하거나 이름을 변경한다고 해 보자.

그럼 이전의 스키마와는 다르게 생긴 스키마가 둥... 나올 것이다.

우리 컴퓨터는 데이터베이스에서 스키마를 자동으로 업데이트해 줄 수 없다.

 

그냥 마구잡이로 바꾼 상태에서 너 알아서 DB에서 가져와줘~~ 하면

얘 없는데?? 아니면 얘 추가됏는데?? 이거 DB 이상한데?? 하고 자꾸 뭐라고 하게 댄다...

 

etc-image-2

일케.

 

앞서 말햇듯 이미 테이블 구조가 설정되어 있는 상태에서 테이블 구조가 바뀌게 되면 충돌 현상이 발생하게 된다.

테이블 구조가 바뀌게 된다면 먼저 테이블 구조가 구성되어 있는 친구에서 이거이거 바뀌었어!! 하고 컴파일러에게 알려주는 코드가 필요하다.

// AppDelegate 내에 작성

    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        // Override point for customization after application launch.
        
        // 스키마 버전이 올라갈 때마다 일일이 번호 올려줘야 함
        let config = Realm.Configuration(schemaVersion: 3) { migration, oldSchemaVersion in
            
            if oldSchemaVersion < 1 { } // memo column 추가
            
            if oldSchemaVersion < 2 { // authors -> author
                migration.renameProperty(onType: BookTable.className(), from: "authors", to: "author")
            }
            
            if oldSchemaVersion < 3 { // bookDescription 추가
                migration.enumerateObjects(ofType: BookTable.className()) { oldObject, newObject in
                    guard let oldObject else { return }
                    guard let newObject else { return }
                    
                    newObject["bookDescription"] = "\(String(describing: oldObject["author"])) · \(String(describing: oldObject["publisher"])) · \(String(describing: oldObject["price"]))"
                }
            }
            
            if oldSchemaVersion < 4 { // price(Int) -> String
                migration.enumerateObjects(ofType: BookTable.className()) { oldObject, newObject in
                    guard let oldObject else { return }
                    guard let newObject else { return }
                }
            }
            
        }
        
        // 적용!!
        Realm.Configuration.defaultConfiguration = config
        
        return true
    }

이 친구는 한 번 적용되면 이후에 어떤 유저가 이전 버전을 사용하고 있을지 모르기 때문에 계속 박혀 있어야 하는 레거시 코드가 된다.

나중에 앱 출시 시에는........... 변경할 때마다 추가해야 하지만? 지금은 시뮬레이터상에서 앱을 삭제했다가 다시 깔면 해결댄다

 

 

맞다!!!!! 마이그레이션 코드를 if else 문으로 쓰면 안 댈까?

-> 절대 안 된다.ᐟ.ᐟ.ᐟ.ᐟ.ᐟ.ᐟ.ᐟ.ᐟ.ᐟ.ᐟ.ᐟ.ᐟ

사용자가 어떤 버전을 쓰고 있을지 모르기 때문에 모든 과정을 거쳐서 스키마 버전이 꼭!! 최신 버전으로 업데이트될 수 있도록 해야 한다.

 

 

 

 

 

 

 

 

 

 

아넘졸려잉

낼 WMO 정리하고 내일 내용도 복습할 수 잇엇음 좋겟다 ..

힘내보자

아근데WMO 과제에 녹이는거까묵엇네~~~!!!!!!

뭔가 진짜 적절하게 사용하면 정말 조은 거 같다

사실뭐든안그렇겟냐마는

그래둥요

좀....... 요즘 잘하고잇는걸까???? 나 ㄱㅊ은걸까????? 하는 생각이 자꾸 드는데 잘 ㅁㄹ겟다..........

과제도 열심히 하는 것 같은데 생각보다 혼자 삽질하는 시간이 길어서... ... 이래도 대나? 싶다 

코드를 작성하면서 고민하는 게 부족한가? 싶다가도 생각해 보면 걍 고민이 문제가 아니라 절대적으로 치는 코드의 양이 부족한 게 아닌가?? 하는 생각도 든다

뭔가 방법이 필요함...

 

아 글구 맨날 약간 구조짜면서나 머 하면서 질문이 생기는데 와이거여쭤바야겟다 싶은 건 항상 왜케 까먹는지

좀 .. 어디 적어놔야겟다 생각나면 바로바로

 

잘하는 사람을 보면서 불안해지면 안대는데 아.. 아조급해져!!!!!!! 사람이 조급해지면 실수부터한다는걸알면서두 참그게쉽지않다

근데 내가 하는 걸 스스로 생각해보면 불안해질수밖에 . . . . . . 머리꿍

 

하몰라 불안할 땐 걍 생각없이 해야 한다

조금 더 열심이 살아보려고 함

점심시간에만 자고 낮잠진짜금지

 

'TIL' 카테고리의 다른 글

[SeSAC] October 3, 2023  (3) 2023.10.04
[SeSAC] September 17, 2023  (0) 2023.09.20
[SeSAC] September 4, 2023  (2) 2023.09.07
[SeSAC] September 1, 2023  (0) 2023.09.02
[SeSAC] August 29, 2023  (2) 2023.08.30
TIL 관련 글
더 보기

티스토리툴바