Post on 08-Oct-2020
liron@gotodba.com
@amitzil
https://gotodba.com
Liron Amitzi
Vancouver, BC Canada
Website:
>=Oracle7 (1998)
Since 2009
Since 2020
President bcoug.org
Senior DB consultant
(since 2002) gotodba.com
Data Integrity
Store and retrieve data
Performance
Flexibility
Data Types and Values
Indexes
Constraints and triggers
Tables and Normalization
ID Low_temp_date Low_temp_F
1 29-DEC-1968 0
2 20-JAN-1985 -27
3 1-JAN-9999 -9999
City
Vancouver
Chicago
Tel Aviv
create table lowest_temp
(id varchar2(10),
city varchar2(100),
low_temp_date varchar2(11),
low_temp_F varchar2(10)
);
create table events
(id NUMBER,
year VARCHAR2(10),
month VARCHAR2(10),
day VARCHAR2(10)
);
ID MONTH DAY
1 2020-01 2020-01-01
YEAR
2020
Index type: ◦ B*Tree
◦ Bitmap
◦ Composite - order is important
◦ Function Based Index
How many?
Autonomous DB
EMPID DEPT CITY
1 IT NY
2 IT SF
3 Sales SF
NAME
Karen
John
Susan
STATE
NY
CA
CA
NAME
IT
Sales
DEPT_ID
10
20
CITY_ID CITY
100 NY
200 SF
STATE
NY
CA
10
10
20
100
200
200
1992 Grover City, CA => Grover Beach, CA
1. UPDATE emp SET city='Grover Beach' Where city='Grover City' AND state='CA'; 2. UPDATE cities SET city='Grover Beach' Where city='Grover City' AND state='CA';
Enforce data type and values
Enforce parent-child relations
Uniqueness
Not null
Triggers - for more complex scenarios
OLTP DWH
Saving space Avoid duplicates Allow duplicates Compress
Data integrity More important Less important
Normalization Normalize De-normalize
Contention Avoid Irrelevant
Performance Instant response Reports
Software for "Books and More"
Books - author, title, date, number of pages, price
Magazines - publication, title, date, frequency, price
Audio - musician, title, date, number of tracks, price
How would you model this information?
How many tables will you need?
id
type
title
date
price
author (b)
num_pages (b)
publication (m)
frequency (m)
musician (a)
num_tracks (a)
ALL_ITEMS:
Very simple
Good performance
Contention (bad for OLTP)
Full downtime for any change / problem
Unnecessary scan of irrelevant data
id
type
title
date
price
publication (m)
frequency (m)
id
type
title
date
price
author (b)
num_pages (b)
id
type
title
date
price
musician (a)
num_tracks (a)
BOOKS MAGAZINES AUDIO
Simple
Good performance
Access only a relevant product
Changing structure of one product doesn't affect others
Less null columns
Adding another product
Querying all products
Search for an item with unknown type
id
author (b)
num_pages (b)
id
type
title
date
price
id
musician (a)
num_tracks (a)
id
publication (m)
frequency (m)
ITEMS
BOOKS
AUDIO
MAGAZINES
Classical and straight forward RDBMS design
Simple to summarize common properties
Search for an item with unknown type
Queries require more joins
Adding another product
id
type
title
date
price
id
prop_name
prop_value ITEMS
id prop_name
1 author
1 num_pages
prop_value
Stephen King
7000
2 musician Pink
PROPS
Amazing flexibility
Adding another product
Entire structure can be changed on the fly
Enforcing constraints
Complex with different datatypes
Have you tried querying it?
A specific author:
SELECT * FROM items
WHERE type='book'
AND id IN (SELECT id FROM props
WHERE
prop_name='author' AND
prop_value='Stephen King')
A specific author OR number of pages:
SELECT * FROM items
WHERE type='book'
AND id IN (SELECT id FROM props
WHERE (prop_name,prop_value) IN
(('author','Stephen King'),
('num_pages',7000))
A specific author AND number of pages:
SELECT * FROM items
WHERE type='book'
AND id IN (SELECT id FROM props
WHERE (prop_name,prop_value) IN
(('author','Stephen King'),
('number_of_pages',7000))
GROUP BY id HAVING count(*)=2)
id
type
title
date
price
other_info (JSON)
ALL_ITEMS:
'{ "author" : "Stephen King", "num_pages" : 7000 }'
Easy for developers to handle
Extremely flexible
Not really RDBMS
Cannot enforce anything (by definition)
A specific author AND number of pages:
SELECT * FROM all_items
WHERE type='book'
AND other_info.author='Stephen King'
AND other_info.num_pages=7000
Performance Flexibility
Data integrity
Querying Space
Another Crazy Design
id
f1
f2
f3
id1
id2
rel_type
f4
f5
OBJECTS RELATIONS
id1 id2
1 3
1 4
rel_type
inheritance
version
2 4 child
4 2 parent
Easy for developers and designers (OOP)
Flexible
Breaks many RDBMS concepts
Foreign keys
Query complexity
Data integrity
liron@gotodba.com
@amitzil
https://gotodba.com
Liron Amitzi