jdbc драйвер за postgresql

еxtensibility - лесно се добавят и махат нови неща

Най-добре е да си пуснеш explain analyze на заявката и да видиш какъв план ти генерира. Аз като си оправих индексите от 10ина милисекунди падна на под милисекунда. Имах около 4-5 джойна. Но в моя случай дори да си беше 10мс, пак си беше ОК като време.

Това мнение е било редактирано от Gamma Goblin на 05-12-2019, 15:51

То зависи с колко данни работиш, но точно тук релационните бази данни отстъпват на документните. Иначе, на индексите няма какво да им оправям - pgadmin-а е нахален и си генерира индекс по подразбиране в момента в който създадеш външен ключ.

Мани другото, ама целя тоя мармалад работи на партишъни (по години). Та join-новете се правят не между 3 таблици а да речем (за 10 години) между 3 * 10 демек между 30 таблици.

За добавяне на данни направих тъп хак с java.sql.Array

Дайте сега оптимално решение за парсване на

Като гледам е CSV + скоби

Иначе класическа обработка. То май така е по-удачно, щото мога да обработя само каквото ми трябва.

Това мнение е било редактирано от thrawn на 05-12-2019, 17:16

или JSONB

Трудно ли се добавя колона а пък защо изобщо бихме махали някога нещо

Трудно ли се добавя колона а пък защо изобщо бихме махали някога нещо

Трудно се добавя защото локва таблицата Ако искаш 99.999 ъптайм не е умно да махаш/добавяш колони. Също ако миграцията се омаже поради някаква причина е много по-лено да се възстанови предишното състояние на базата.

Представи си, 10-20 таблици в които ги има тия данни и решиш да добавиш поле. Трябва да редактира всяка таблица. После трябва да редактираш всички заявки които ги манипулират тия данни.
Или пък имаш поле с check constraint и промениш филтъра (да речем, добавяш формат).

Вместо да направиш само една промяна то трябва да препипаш цялата база данни и цялата кодова база за да си сигурен, че промяната е отразена навсякъде.
Също така, има вариант при които вмъкването на данни е във формат insert into tbl values (....) и добавянето на поле би убило заявката (ако я прави софтуер който не е под твой контрол това е недопустимо).

Та варианти за релация 1:1 има много и реално такива релации се ползват често.

Пример от тая база данни - имаш таблици които описват продажби, имаш таблици които описват сторно операции. Тия таблици включват различни данни но трябва да включват и данни за фискалния документ който е издаден към тях (номер ФУ, номер ФП, номер документ, дата, час, сума...). Та релацията с таблицата с документите ми е 1:1. Така получавам възможност за извличане на всички фискални документи с обхождане на една таблица. В противен случай се минава през union.

Практически няма нищо сложно но добрия дизайн на базата данни спестява доста хамалогия в последствие. Затова и зорът ми с тия UDT е да докарам четенето и записът на тия данни до един ред (не, че е трудно да го направя с 30 например).

споредм мен е най-добре да ползваш jsonb ако драйвера го поддържа

Оставих го с udt. Така или иначе, си има "оперативни" данни в които първо се прави директен запис (upsert) преди да се запише самия документ, та просто създадох няколко функции които по ид връщат съответния запис. Така хем го докарах до един ред, хем си запазих възможността да ползвам сесийните параметри за да задавам стойности по defaut за доставчик, търговски обект и потребител.

С четенето си остава мотиката, но в края на краищата не е чак такава болка. Пък и винаги има надежда, че спецификациите на jdbc ще бъдат имплантирани в официалния драйвер.