1 или две таблици

Не питам в SO, защото по тамошните критерии е офтопик


1. Първи вариант

2. Втори вариант

Цялата работа е че искам да рънна

, което физически сортира демо таблицата в index-order. Идеята е че се правят заявки по даден ключ и ако се намират в една страница ще се прави по малко random reads и по-малко ИО операции.

Обаче за да работи това нещо, last_seen трябва да е в отделна таблица защото ъпдейтите разбъркват таблицата, а last_seen е ъпдейтва много често и прави клъстеризирането на демо таблицата безсмислено.


Та според вас заслужава ли си сложнотията ?

Това мнение е било редактирано от Gamma Goblin на 13-08-2019, 09:41

Пробвал ли си да измериш двата варианта да видиш дали има ускорение и дали си заслужава? Ще правиш ли JOIN към last_seen като извличаш данните?

ами не съм още


Принципно в демо таблицата само ще се пише, и last_seen е необходим само когато ще се трие (много рядко), така че джойна е без значение дали ще е бавен.

Тъпото е че INSERT-a става много по-сложен с две таблици. Сега правя

,
докато с две таблици нещата ще станат по-сложни

Ако операцията за търсене наистина е по-ефикасна си струва. Това, че правиш релация 1:1 не е някакво изключение а честа практика. Не виждам какво те притеснява това.

Мен по ме притеснява идеята за физическо сортиране на данни в таблиците. Не се сещам за причина това да е необходимо.

https://bclennox.com/the-postgres-cluster-command

За партишън таблици не се ползва физическо сортиране. Просто данните си отиват в различните партишъни. Тук обаче има една мотика - нямаш първични ключове за цялата таблица (само за отделните партишъни). Затова аз ползвам партишъни само за хистори данни.

Всъщност, изобщо нямаш първични ключове а само уникални (за партишъна).

От 12 та версия външните ключове вече работят и за партишън таблиците.