daviddoji/professional-programming
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Run prettier everywhere

Browse Source
This commit is contained in:
Charles-Axel Dein
2020-07-21 09:14:24 +02:00
parent 6f941a8ab3
commit c328d43192
13 changed files with 743 additions and 785 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
antipatterns/database-antipatterns.md
View File

@@ -1,5 +1,6 @@
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
# Table of Contents
- [Database anti-patterns](#database-anti-patterns)
@@ -7,11 +8,9 @@
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
Database anti-patterns
======================
# Database anti-patterns
Using `VARCHAR` instead of `TEXT` (PostgreSQL)
----------------------------------------------
## Using `VARCHAR` instead of `TEXT` (PostgreSQL)
Unless you absolutely restrict the width of a text column for data consistency
reason, don't do it.
@@ -22,9 +21,9 @@ shows that there's fundamentally no difference in performance between
`char(n)`, `varchar(n)`, `varchar` and `text`. Here's why you should pick
`text`:
* `char(n)`: takes more space than necessary when dealing with values shorter
- `char(n)`: takes more space than necessary when dealing with values shorter
than n.
* `varchar(n)`: it's difficult to change the width.
* `varchar` is just like `text`.
* `text` does not have the width problem that `char(n)` and `varchar(n)` and
- `varchar(n)`: it's difficult to change the width.
- `varchar` is just like `text`.
- `text` does not have the width problem that `char(n)` and `varchar(n)` and
has a cleaner name than `varchar`.