Zastosowanie tabel słownikowych

Zastosowanie tabel słownikowych
0

Witam!
Jestem osobą początkującą w tej dziedzinie, dlatego chciałbym prosić was o pomoc w wyjaśnieniu kilku kwestii. Mianowicie jakie jest zastosowanie i kiedy używać tabel słownikowych, czy tabele te biorą udział w relacjach pomiędzy innymi tabelami?
pozdrawiam

Shalom
  • Rejestracja:około 21 lat
  • Ostatnio:prawie 3 lata
  • Lokalizacja:Space: the final frontier
  • Postów:26433
2

Wyobraź sobie że przechowujesz w bazie adresy klientów i masz tam miasto i nazwę ulicy. Jeśli nie masz miasta i ulicy w słowniku to może się okazać że u jednego klienta będzie to napisane z dużej litery, u drugiego z małej, u jednego bez polsków znaków u innego ze znakami itd. W efekcie w bazie jedna i ta sama ulica będzie wpisana na 20 różnych sposobów. Teraz wyobraź sobie że nazwa ulicy się zmieniła. Klientów masz milion.
Pytanie: ile czasu zajmie ci zmiana w bazie tych wszystkich adresów na poprawne (tzn podmiana starej nazwy ulicy na nową)?
A teraz ile czasu by to zajęło gdyby Klient w bazie miał tylko ID ze słownika gdzie byłoby miasto i ulica? Otóż w tym przypadku zmodyfikowałbyś jedynie wpis w słowniku ze starej nazy ulicy na nową.


"Nie brookliński most, ale przemienić w jasny, nowy dzień najsmutniejszą noc - to jest dopiero coś!"
somekind
BTW - jak "tabela słownikowa" nazywa się po angielsku?
Shalom
Nie wiem ;]
0

Dziękuje za odpowiedź, super przykład :) pozdrawiam

WL
  • Rejestracja:około 21 lat
  • Ostatnio:11 dni
  • Postów:1082
1

Piękny przykład na znormalizowaną bazę danych, tylko zupełnie nieprzydatny w przypadku realnego systemu. Po co przechowywać ulicę w osobnej tabeli? Żeby to łączyć z tabela słownikową przy każdym wyświetleniu? I analogicznie w przypadku miejscowości, kodu pocztowego nr domu itd.? Bo przecież wszystkie w/w informacje mogą się powtórzyć. Oczywiście można w bazie trzymać całą bazę danych terytorialnych (a więc powiązania województwo->Powiat->Gmina->Kod pocztowy->Miejscowość->Ulica->Nr domu/mieszkania), tyle że przy większości zastosowań ilość danych na bazę terytorialną przekroczy rozmiar danych biznesowych.
Jest sens? Moim zdaniem nie bardzo... No chyba, że klientów faktycznie będzie zylion - to wtedy tak. Tyle, zę wtedy cały taki system ciut inaczej się projektuje.
A i tak uważam, że lepszym pomysłem jest już dedykowana usługa (np. REST), która serwuje tego typu informacje dla aplikacji. No, ale do tego trzeba mieć jakiś serwer ogólnie dostępny itd.

Tabel słownikowych używam do takich rzeczy jak;

  1. Statusu dokumentów
  2. Rodzaje/typy obiektów, które służą do segmentacji danych (typ towaru - produkt, opakowanie, usługa, itd.).
  3. I wszystkie podobne byty jak wyżej...
    Nie traktuję jako słownik takich danych jak dane adresowe, kategorie kontrahenta/towaru, itd. Ogólnie rzecz biorąc - dane, które są niezbędne z punktu widzenia logiki aplikacji to jest słownik. Dane, którymi w całości zarządza użytkownik i które nie są bezpośrednio odwzorowane w logice programu - to nie jest słownik w moim rozumieniu.

Czy tabele słownikowe powinny brać udział w relacjach? Moim zdaniem nie powinny, bo to tylko niepotrzebny narzut na bazę. Zauważ, że pozycji w słowniku (takim słowniku, jak go opisałem czym jest) jest raptem kilka (no może kilkanaście) a więc selektywność takich danych w kolumnie konkretnej tabeli też jest niska. A niska selektywność stawia pod znakiem zapytania sens zakładania indeksu na takiej kolumnie.
Całym słownikiem (u mnie) zarządza aplikacja, a sama tabela słownikowa z punktu widzenia bazy danych, jest tylko składowiskiem danych dla słowników bez żadnej logiki i relacji z pozostałymi tabelami.

Shalom
Jasne że mój przykład jest mało realistyczny, ale nie miał prezentować realnego zastosowania, tylko w sposób przejaskrawiony samą potrzebę istnienia słowników. W rzeczywistości przecież większość aplikacji korzysta z ORMów a słowniki generują sie automatycznie z Enumów ;]
WL
To prawda, że najczęściej. Ale sam wolę mieć lekko większa elastyczność i słownik nie zależy od typów wyliczeniowych. Ma to swoje zalety, ale ma i tez pewne wady - tak czy siak bilans dla mnie jest na plus. Ale i mam ciut bardziej specyficzne wymagania.
fourfour
  • Rejestracja:prawie 11 lat
  • Ostatnio:ponad 8 lat
  • Postów:627
0
wloochacz napisał(a):

(..)
Całym słownikiem (u mnie) zarządza aplikacja, a sama tabela słownikowa z punktu widzenia bazy danych, jest tylko składowiskiem danych dla słowników bez żadnej logiki i relacji z pozostałymi tabelami.

Kompletnie, całkowicie "luźna" tabela, bez żadnego powiązania? Dopuszczasz (przykładowo), że błąd w aplikacji spowoduje wpisanie do jakiejś tabeli nieistniejącego w tabeli słownikowej ID?

Sarrus
  • Rejestracja:prawie 14 lat
  • Ostatnio:10 dni
  • Postów:2512
1
wloochacz napisał(a):

Piękny przykład na znormalizowaną bazę danych, tylko zupełnie nieprzydatny w przypadku realnego systemu. Po co przechowywać ulicę w osobnej tabeli? Żeby to łączyć z tabela słownikową przy każdym wyświetleniu? I analogicznie w przypadku miejscowości, kodu pocztowego nr domu itd.? Bo przecież wszystkie w/w informacje mogą się powtórzyć. Oczywiście można w bazie trzymać całą bazę danych terytorialnych (a więc powiązania województwo->Powiat->Gmina->Kod pocztowy->Miejscowość->Ulica->Nr domu/mieszkania), tyle że przy większości zastosowań ilość danych na bazę terytorialną przekroczy rozmiar danych biznesowych.
Jest sens? Moim zdaniem nie bardzo...

Masz ograniczone spojrzenie do tego co robiłeś i mylisz się bardzo. Serwis REST fajnie, ale skąd ten serwis ma brać dane? Przeszukiwanie plików xml? Słabe. Poza tym przy masowym wprowadzaniu danych, wpisuje się kod pocztowy i dane adresowe muszą się pokazywać w przeciągu sekundy. Kolejny przykład, to gdy musisz przeprowadzać analizy na podstawie danych lokalizacyjnych i nie masz kodu pocztowego. To czy jest sens czy nie zależy od danego systemu

WL
  • Rejestracja:około 21 lat
  • Ostatnio:11 dni
  • Postów:1082
0
fourfour napisał(a):
wloochacz napisał(a):

(..)
Całym słownikiem (u mnie) zarządza aplikacja, a sama tabela słownikowa z punktu widzenia bazy danych, jest tylko składowiskiem danych dla słowników bez żadnej logiki i relacji z pozostałymi tabelami.

Kompletnie, całkowicie "luźna" tabela, bez żadnego powiązania?

Tak, całkowicie luźna.

Dopuszczasz (przykładowo), że błąd w aplikacji spowoduje wpisanie do jakiejś tabeli nieistniejącego w tabeli słownikowej ID?

I tak i nie; po prostu nie posługuje się ID z tabeli słownikowej, tylko wartością słownika - można rzec, wartością typu wyliczeniowego dla konkretnego słownika.

edytowany 1x, ostatnio: wloochacz
WL
  • Rejestracja:około 21 lat
  • Ostatnio:11 dni
  • Postów:1082
0
Sarrus napisał(a):
wloochacz napisał(a):

Piękny przykład na znormalizowaną bazę danych, tylko zupełnie nieprzydatny w przypadku realnego systemu. Po co przechowywać ulicę w osobnej tabeli? Żeby to łączyć z tabela słownikową przy każdym wyświetleniu? I analogicznie w przypadku miejscowości, kodu pocztowego nr domu itd.? Bo przecież wszystkie w/w informacje mogą się powtórzyć. Oczywiście można w bazie trzymać całą bazę danych terytorialnych (a więc powiązania województwo->Powiat->Gmina->Kod pocztowy->Miejscowość->Ulica->Nr domu/mieszkania), tyle że przy większości zastosowań ilość danych na bazę terytorialną przekroczy rozmiar danych biznesowych.
Jest sens? Moim zdaniem nie bardzo...

Masz ograniczone spojrzenie do tego co robiłeś i mylisz się bardzo.

W którym miejscu mam ograniczone spojrzenie i bardzo się mylę?

Serwis REST fajnie, ale skąd ten serwis ma brać dane? Przeszukiwanie plików xml? Słabe.

W tej chwili, to nieistotne skąd ma pobierać dane. Istotne, że ma serwować dane.
Czy XML jest słaby? Zależy jak się go używa (i za pomocą czego - nie uważam, żeby np. Terradata była słaba) i do czego - nie zawsze jest słaby. Ale powiedzmy, że bazą danych dla takiej usługi może być np. SQLite. Lepiej?

Poza tym przy masowym wprowadzaniu danych, wpisuje się kod pocztowy i dane adresowe muszą się pokazywać w przeciągu sekundy.

Przy masowaym wprowadzaniu danych nic się nikomu nie pokazuje, bo przecież aplikacja działa w trybie wsadowym - prawda?
Dwa - w takim przypadku używam dynamicznego keszowania takiego słownika, ale to naprawdę nie ten temat...

Kolejny przykład, to gdy musisz przeprowadzać analizy na podstawie danych lokalizacyjnych i nie masz kodu pocztowego. To czy jest sens czy nie zależy od danego systemu

I dokładnie to napisałem, a więc nie ma jednego złotego środka na wszystko.

Sarrus
  • Rejestracja:prawie 14 lat
  • Ostatnio:10 dni
  • Postów:2512
0
wloochacz napisał(a):

Masz ograniczone spojrzenie do tego co robiłeś i mylisz się bardzo.

W którym miejscu mam ograniczone spojrzenie i bardzo się mylę?
Chodziło mi o to, że są przypadki gdzie sens jest.

Serwis REST fajnie, ale skąd ten serwis ma brać dane? Przeszukiwanie plików xml? Słabe.

W tej chwili, to nieistotne skąd ma pobierać dane. Istotne, że ma serwować dane.
Czy XML jest słaby? Zależy jak się go używa (i za pomocą czego - nie uważam, żeby np. Terradata była słaba) i do czego - nie zawsze jest słaby. Ale powiedzmy, że bazą danych dla takiej usługi może być np. SQLite. Lepiej?
Zjadłem snickersa - lepiej ;)

Poza tym przy masowym wprowadzaniu danych, wpisuje się kod pocztowy i dane adresowe muszą się pokazywać w przeciągu sekundy.
Przy masowaym wprowadzaniu danych nic się nikomu nie pokazuje, bo przecież aplikacja działa w trybie wsadowym - prawda?
Chodziło mi o takie systemy, gdzie siedzi ileś klepaczy i wklepuje dane z kuponów w tempie 100 na godzinę.

Kolejny przykład, to gdy musisz przeprowadzać analizy na podstawie danych lokalizacyjnych i nie masz kodu pocztowego. To czy jest sens czy nie zależy od danego systemu

I dokładnie to napisałem, a więc nie ma jednego złotego środka na wszystko.

Nie zauważyłem tego, ale cieszę się że się jednak zgadzamy :)

edytowany 5x, ostatnio: Sarrus
WL
  • Rejestracja:około 21 lat
  • Ostatnio:11 dni
  • Postów:1082
0
Sarrus napisał(a):
wloochacz napisał(a):

Masz ograniczone spojrzenie do tego co robiłeś i mylisz się bardzo.

W którym miejscu mam ograniczone spojrzenie i bardzo się mylę?
Chodziło mi o to, że są przypadki gdzie sens jest.

Zauważ, że opisałem jak ja rozumiem słownik i dlaczego w moim rozumieniu słownika nie ma to sensu.

Serwis REST fajnie, ale skąd ten serwis ma brać dane? Przeszukiwanie plików xml? Słabe.

W tej chwili, to nieistotne skąd ma pobierać dane. Istotne, że ma serwować dane.
Czy XML jest słaby? Zależy jak się go używa (i za pomocą czego - nie uważam, żeby np. Terradata była słaba) i do czego - nie zawsze jest słaby. Ale powiedzmy, że bazą danych dla takiej usługi może być np. SQLite. Lepiej?
Zjadłem snickersa - lepiej ;)

Poza tym przy masowym wprowadzaniu danych, wpisuje się kod pocztowy i dane adresowe muszą się pokazywać w przeciągu sekundy.
Przy masowaym wprowadzaniu danych nic się nikomu nie pokazuje, bo przecież aplikacja działa w trybie wsadowym - prawda?
Chodziło mi o takie systemy, gdzie siedzi ileś klepaczy i wklepuje dane z kuponów w tempie 100 na godzinę.

Ale to nie jest masowe wprowadzanie danych, tylko po prostu wprowadzanie danych przez użytkowników za pomocą interfejsu aplikacji. Taka normalna praca z programem...

Kolejny przykład, to gdy musisz przeprowadzać analizy na podstawie danych lokalizacyjnych i nie masz kodu pocztowego. To czy jest sens czy nie zależy od danego systemu

I dokładnie to napisałem, a więc nie ma jednego złotego środka na wszystko.

Nie zauważyłem tego, ale cieszę się że się jednak zgadzamy :)

Żeby była jasność - uważam, że nie zawsze najlepszym rozwiązaniem w realnym systemie jest normalizaja bazy danych, czy tez twarde trzymanie się np. trzeciej postaci normalnej w każdym przypadku.

Sarrus
No tak, to zależy od wymagań i specyfiki aplikacji i tyle. Nie ma już co dyskutować.
somekind
Moderator
  • Rejestracja:prawie 17 lat
  • Ostatnio:3 dni
  • Lokalizacja:Wrocław
3
wloochacz napisał(a):

Piękny przykład na znormalizowaną bazę danych, tylko zupełnie nieprzydatny w przypadku realnego systemu.

W której szkole tak powiedzieli?

Po co przechowywać ulicę w osobnej tabeli? Żeby to łączyć z tabela słownikową przy każdym wyświetleniu? I analogicznie w przypadku miejscowości, kodu pocztowego nr domu itd.?

Żeby mieć realne dane. Niektórzy ludzie lubią mieć w swoich bazach wartości rzeczywiste, a nie losowe.

wloochacz napisał(a):

Oczywiście można w bazie trzymać całą bazę danych terytorialnych (a więc powiązania województwo->Powiat->Gmina->Kod pocztowy->Miejscowość->Ulica->Nr domu/mieszkania)

Kod pocztowy wiąże się z ulicą, a nie z miejscowością. Hierarchię struktury administracyjnej można trzymać w jednej tabeli, kody pocztowe oraz ulice w drugiej.

tyle że przy większości zastosowań ilość danych na bazę terytorialną przekroczy rozmiar danych biznesowych.

No i? Cała Polska to chyba i tak mniej niż 50 MB.

Tabel słownikowych używam do takich rzeczy jak;

Statusu dokumentów
Rodzaje/typy obiektów, które służą do segmentacji danych (typ towaru - produkt, opakowanie, usługa, itd.).
I wszystkie podobne byty jak wyżej...

Nie traktuję jako słownik takich danych jak dane adresowe, kategorie kontrahenta/towaru, itd. Ogólnie rzecz biorąc - dane, które są niezbędne z punktu widzenia logiki aplikacji to jest słownik. Dane, którymi w całości zarządza użytkownik i które nie są bezpośrednio odwzorowane w logice programu - to nie jest słownik w moim rozumieniu.

Słownik to dane populowane, które są niezmieniane przez użytkownika. Pod tę definicję podchodzą zarówno rzeczy, które wymieniłeś, jak i dane adresowe.

Czy tabele słownikowe powinny brać udział w relacjach?

Tabele nie biorą udziału w relacjach tylko nimi są.

Moim zdaniem nie powinny, bo to tylko niepotrzebny narzut na bazę.

Napisał człowiek, który chce dane adresowe zwracać z usługi restowej zamiast lokalnej bazy danych.

Całym słownikiem (u mnie) zarządza aplikacja, a sama tabela słownikowa z punktu widzenia bazy danych, jest tylko składowiskiem danych dla słowników bez żadnej logiki i relacji z pozostałymi tabelami.

Tja, właśnie poprawiam aplikację ludzi o takim podejściu. No bo po co komu integralność referencyjna, przecież to tylko debilny narzut na wydajność. A, że potem pojawią się jakieś rekordy-widmo, to przecież żaden problem, bo autora przecież wtedy już nie będzie przy swoim genialnym wytworze.

Wyobraź sobie, że ludzie często nie są aż tacy głupi, żeby chcieć wprowadzać niepoprawne dane do aplikacji, co dotyczy także nieistniejących miast, ulic i kodów pocztowych. Umieszczenie w aplikacji realnej bazy danych terytorialnych, znacząco im to ułatwia. Zwłaszcza, jeśli aplikacja posiada też funkcję podpowiadania i wyszukiwania.
Jeśli danych biznesowych ma być mniej niż adresowych, to nie ma się co przejmować narzutem na złączenia. Bez sensu jest optymalizować problemy wydajnościowe, których nie ma i przy naszych założeniach nie będzie.
A jeśli zakładamy lub stwierdzimy w rzeczywistym przypadku, że są, to zawsze można odkładać kopię danych adresowych w tabeli biznesowej albo użyć widoków zmaterializowanych. Tylko to nie znaczy, że nie ma sensu od początku trzymać sensownej struktury słownika adresów w bazie.


Po dopracowaniu rozwiązania każdy będzie mógł założyć własny drzewiasty wątek.
DibbyDum
  • Rejestracja:ponad 12 lat
  • Ostatnio:ponad rok
  • Lokalizacja:Polska, Kraków
0

Jak by ktoś był ciekaw jak wygląda spis terytorialny udostępniony przez gus: http://www.stat.gov.pl/broker/access/index.jspa
Ale niestety nie ma integracji danych z kodami pocztowymi, które można kupić od poczty polskiej ale nie są do końca zgodne z TERYT'em . ;)


Yubby dibby dibby dibby dibby dibby dibby dum..
NE
  • Rejestracja:ponad 10 lat
  • Ostatnio:prawie 8 lat
  • Postów:39
0

Piękny przykład na znormalizowaną bazę danych, tylko zupełnie nieprzydatny w przypadku realnego systemu.

A co masz pod haslem realny system. Chciał bym ja zobaczyc jak system zarządzania NFZ, czy Policją, czy Google byl bez słownioków. Ty sobie wyobrażasz jak baza by zaczęła puchnąć po 2 miesiącach musieli by kupowac nowe dyski zeby dane zbierać.

WL
Najpierw przeczytaj ze zrozumieniem co napisałem, potem komentuj.
Kliknij, aby dodać treść...

Pomoc 1.18.8

Typografia

Edytor obsługuje składnie Markdown, w której pojedynczy akcent *kursywa* oraz _kursywa_ to pochylenie. Z kolei podwójny akcent **pogrubienie** oraz __pogrubienie__ to pogrubienie. Dodanie znaczników ~~strike~~ to przekreślenie.

Możesz dodać formatowanie komendami , , oraz .

Ponieważ dekoracja podkreślenia jest przeznaczona na linki, markdown nie zawiera specjalnej składni dla podkreślenia. Dlatego by dodać podkreślenie, użyj <u>underline</u>.

Komendy formatujące reagują na skróty klawiszowe: Ctrl+B, Ctrl+I, Ctrl+U oraz Ctrl+S.

Linki

By dodać link w edytorze użyj komendy lub użyj składni [title](link). URL umieszczony w linku lub nawet URL umieszczony bezpośrednio w tekście będzie aktywny i klikalny.

Jeżeli chcesz, możesz samodzielnie dodać link: <a href="link">title</a>.

Wewnętrzne odnośniki

Możesz umieścić odnośnik do wewnętrznej podstrony, używając następującej składni: [[Delphi/Kompendium]] lub [[Delphi/Kompendium|kliknij, aby przejść do kompendium]]. Odnośniki mogą prowadzić do Forum 4programmers.net lub np. do Kompendium.

Wspomnienia użytkowników

By wspomnieć użytkownika forum, wpisz w formularzu znak @. Zobaczysz okienko samouzupełniające nazwy użytkowników. Samouzupełnienie dobierze odpowiedni format wspomnienia, zależnie od tego czy w nazwie użytkownika znajduje się spacja.

Znaczniki HTML

Dozwolone jest używanie niektórych znaczników HTML: <a>, <b>, <i>, <kbd>, <del>, <strong>, <dfn>, <pre>, <blockquote>, <hr/>, <sub>, <sup> oraz <img/>.

Skróty klawiszowe

Dodaj kombinację klawiszy komendą notacji klawiszy lub skrótem klawiszowym Alt+K.

Reprezentuj kombinacje klawiszowe używając taga <kbd>. Oddziel od siebie klawisze znakiem plus, np <kbd>Alt+Tab</kbd>.

Indeks górny oraz dolny

Przykład: wpisując H<sub>2</sub>O i m<sup>2</sup> otrzymasz: H2O i m2.

Składnia Tex

By precyzyjnie wyrazić działanie matematyczne, użyj składni Tex.

<tex>arcctg(x) = argtan(\frac{1}{x}) = arcsin(\frac{1}{\sqrt{1+x^2}})</tex>

Kod źródłowy

Krótkie fragmenty kodu

Wszelkie jednolinijkowe instrukcje języka programowania powinny być zawarte pomiędzy obróconymi apostrofami: `kod instrukcji` lub ``console.log(`string`);``.

Kod wielolinijkowy

Dodaj fragment kodu komendą . Fragmenty kodu zajmujące całą lub więcej linijek powinny być umieszczone w wielolinijkowym fragmencie kodu. Znaczniki ``` lub ~~~ umożliwiają kolorowanie różnych języków programowania. Możemy nadać nazwę języka programowania używając auto-uzupełnienia, kod został pokolorowany używając konkretnych ustawień kolorowania składni:

```javascript
document.write('Hello World');
```

Możesz zaznaczyć również już wklejony kod w edytorze, i użyć komendy  by zamienić go w kod. Użyj kombinacji Ctrl+`, by dodać fragment kodu bez oznaczników języka.

Tabelki

Dodaj przykładową tabelkę używając komendy . Przykładowa tabelka składa się z dwóch kolumn, nagłówka i jednego wiersza.

Wygeneruj tabelkę na podstawie szablonu. Oddziel komórki separatorem ; lub |, a następnie zaznacz szablonu.

nazwisko;dziedzina;odkrycie
Pitagoras;mathematics;Pythagorean Theorem
Albert Einstein;physics;General Relativity
Marie Curie, Pierre Curie;chemistry;Radium, Polonium

Użyj komendy by zamienić zaznaczony szablon na tabelkę Markdown.

Lista uporządkowana i nieuporządkowana

Możliwe jest tworzenie listy numerowanych oraz wypunktowanych. Wystarczy, że pierwszym znakiem linii będzie * lub - dla listy nieuporządkowanej oraz 1. dla listy uporządkowanej.

Użyj komendy by dodać listę uporządkowaną.

1. Lista numerowana
2. Lista numerowana

Użyj komendy by dodać listę nieuporządkowaną.

* Lista wypunktowana
* Lista wypunktowana
** Lista wypunktowana (drugi poziom)

Składnia Markdown

Edytor obsługuje składnię Markdown, która składa się ze znaków specjalnych. Dostępne komendy, jak formatowanie , dodanie tabelki lub fragmentu kodu są w pewnym sensie świadome otaczającej jej składni, i postarają się unikać uszkodzenia jej.

Dla przykładu, używając tylko dostępnych komend, nie możemy dodać formatowania pogrubienia do kodu wielolinijkowego, albo dodać listy do tabelki - mogłoby to doprowadzić do uszkodzenia składni.

W pewnych odosobnionych przypadkach brak nowej linii przed elementami markdown również mógłby uszkodzić składnie, dlatego edytor dodaje brakujące nowe linie. Dla przykładu, dodanie formatowania pochylenia zaraz po tabelce, mogłoby zostać błędne zinterpretowane, więc edytor doda oddzielającą nową linię pomiędzy tabelką, a pochyleniem.

Skróty klawiszowe

Skróty formatujące, kiedy w edytorze znajduje się pojedynczy kursor, wstawiają sformatowany tekst przykładowy. Jeśli w edytorze znajduje się zaznaczenie (słowo, linijka, paragraf), wtedy zaznaczenie zostaje sformatowane.

  • Ctrl+B - dodaj pogrubienie lub pogrub zaznaczenie
  • Ctrl+I - dodaj pochylenie lub pochyl zaznaczenie
  • Ctrl+U - dodaj podkreślenie lub podkreśl zaznaczenie
  • Ctrl+S - dodaj przekreślenie lub przekreśl zaznaczenie

Notacja Klawiszy

  • Alt+K - dodaj notację klawiszy

Fragment kodu bez oznacznika

  • Alt+C - dodaj pusty fragment kodu

Skróty operujące na kodzie i linijkach:

  • Alt+L - zaznaczenie całej linii
  • Alt+, Alt+ - przeniesienie linijki w której znajduje się kursor w górę/dół.
  • Tab/⌘+] - dodaj wcięcie (wcięcie w prawo)
  • Shit+Tab/⌘+[ - usunięcie wcięcia (wycięcie w lewo)

Dodawanie postów:

  • Ctrl+Enter - dodaj post
  • ⌘+Enter - dodaj post (MacOS)