niekoniecznie. SQLite operuje na danych dyskowych i nie zawsze daje się zmusić do trzymania bufora w pamięci. Jeżeli masz powolny dysk flash, to wątki zostaną zablokowane oczekiwaniem na wejście/wyjście. Jeżeli zwykła zmiana bazy znacznie zwiększyła responsywność aplikacji, to mówi samo za siebie.

http://www.sqlite.org/inmemorydb.html
tia…

czy ja gdzieś twierdziłem, że nie da się stworzyć bazy SQLite w pamięci operacyjnej? to, co napisałem, a to, co Ty znalazłeś w dokumentacji, to zupełnie różne rzeczy

Jak zawsze w takim wypadku zależy od zastosowań. Jednak zauważam że coraz częściej mówi się ostatnio o innych projektach jak choćby Cassandra.

@przemo_li – Tak jak Sit powiedział, wszystko zależy od zastosowań. Nie ma czegoś takiego jak jedno narzędzie do wszystkiego. Przykładowo, jeśli dane się zmieniają często, ale zapytania są stałe, to wtedy najlepsze są właśnie nierelacyjne DB. Przykładem istniejącym jest tu naliczanie billingów ze strony operatorów sieci komórkowych dla milionów klientów. Tak jak kiedyś słyszałem, tam w ogóle nie stosuje się relacyjnych DB bo szkoda marnować zasoby serwera na obsługę warstwy abstrakcji zwanej modelem relacyjnym. Zastosuj tam takiego Oracle to wtedy byś zobaczył ile razy trzeba zwiększyć liczbę serwerów DB

Sęk w tym, że telekomy używają do tego właśnie relacyjnych baz danych. Np. Polkomtel jedzie na Oracle i Teradata.

Nie widzę też niby gdzie model relacyjny “marnuje zasoby na dodatkową warstwę abstrakcji”. Masz na myśli czas potrzebny na kompilację i optymalizację zapytań? Tj. milisekundy w stosunku do godzin na policzenie billingu?

A co do modnych ostatnio baz nierelacyjnych: nie ma to jak uniknięcie problemu skalowalności powiązanych ze sobą transakcyjnych danych poprzez… zabronienie wiązania ze sobą danych i brak transakcyjności.

@abcman

Najlepszość niejedno ma imię. Telekomy jadą akurat właśnie na Oracle’u Tak, również w systemach “onlajn-czardżing”
I w tych zastosowaniach, cena sprzętu jest naprawdę drugorzędna
A oracle jest dlatego, że vendor może sobie przykleić znaną metkę
i akurat dane billingowe są b. dobrze ustrukturyzowane.

@Królik, Budyń – Czytałem w jakimś numerze SDJ że telekomy często używają nierelacyjnych baz danych w niektórych zastosowaniach. To co więc mówiłem, nie jest oparta na moim widzimisię.

@Królik – Nie widzisz? To zobacz różnicę w efektywności relacyjnych i nierelacyjnych baz danych dla wielkich prędkości przetwarzania. Rekordy w takich prędkościach należą do tych drugich właśnie.

Brak transakcyjności to wada? Owszem, ale w relacyjnych DB. Po co Ci transakcje w nierelacyjnych DB? Żeby więcej pieniędzy na większy serwer wydać? Bo jeśli chodzi o spójność danych, to wszystko jest w tych nierel. w porządku.

“o zobacz różnicę w efektywności relacyjnych i nierelacyjnych baz danych dla wielkich prędkości przetwarzania.”

To ja poproszę linka do tych rekordów
Ale nie że ktoś sobie coś w domu zmierzył i opisał na blogu, tylko do recenzowanego artykułu.

“Brak transakcyjności to wada? Owszem, ale w relacyjnych DB”

Co ma piernik do wiatraka? Od kiedy używanie nierelacyjnej bazy gwarantuje, że sprzęt pod nią się nie sypnie? Albo że dwóch na raz będzie chciało czytać / pisać te same dane?

Hmm. Z tego co wiem problemem nierelacyjnych baz danych jest brak odpowiednio rozpracowanego kwasu[1] (ACID ).

“Po co Ci transakcje w nierelacyjnych DB?”

Hmm. Z tych samych powodów co potrzebuje ‘tranzakcji’ w programowaniu za pomocą semaforów/algorytmów lock-free?

[1] K – ???
W – wieczność (durability
A – atomiczność
S – spójność

K – jak isolation: kapsułkowanie

poeta ze mnie marny, ale starałem się

“Hmm. Z tych samych powodów co potrzebuje ‘tranzakcji’ w programowaniu za pomocą semaforów/algorytmów lock-free”

Tyle że programowanie przy użyciu semaforów i alg. lock-free to wyższa szkoła jazdy (i niższy poziom abstrakcji). Raczej wszystko idzie w kierunku zastąpienia tego modelu programowania innymi (CSP, STM), niż przenoszeniu go na grunt baz danych.

@Królik, @Budyn – prosze, oto link do artykulu: http://www.allthingsdistributed.com/2008/12/eventually_consistent.html

Ludzie podniecają się tym NoSQL tylko że problem jest zupełnie gdzie indziej. Bazy relacyjne są bazami uniwersalnymi (aby cos uniwersalnego działało optymalnie musi by skonfigurowane), bazy danych nierelacyjne są bazami specjalizowanymi do danego zastosowania (mniej konfigurowania, kosztem elastyczności).
System oparty o bazę relacyjną może śmigac ale do optymalnego działania potrzebni są ludzie którzy wiedzą że:
- bazy danych nie można traktowac jako black box
- właściwy model to 60% sukcesu ( modelowanie struktur to najważniejszy etap tworzeni aplikacji/systemu, trzeba wiedziec kiedy mozna rozszerzyc tabele a kiedy wskazane jest rozbicie na kilka tabel)
- NULL jest wbrew pozorom bardzo kosztowny
- trzymanie blobów/plików w bazie danych to generalnie zły pomysł(tak naprawdę koncepcja “worka na dane” to w bazach relacyjnych totalna porażka)
Dodatkowo mało osób “orientuje” się w relacyjnych bazach danych. Nikt nie uczy teorii baz danych, więc większośc nie ma pojęcia jak to naprawdę działa. A nawet jak się ktoś uczył nie znaczy że to rozumie . Większośc uzywa ORM’ów(wbijcie sobie do głowy że to się nie nadaje do skomplikowanych zapytań, ba robi problemy przy prostych zapytaniach) i mitów typu (join jest szybszy od IN) mimo że jest to zależne od ilości wartości w złączeniu.
Moj kierownik był bardzo zdziwiony gdy mu udowodniłem że typ danych ‘ala prefix’ (mimo że same cyfry ) był bardziej wydajny na typie tekstowym, pózniej probował na sile wrzucac analogie do innych intow, wiec musiałem przedstawic budowe indeksu btree ze wzgledu na typ danych.
@abcman akurat tego testu nie widziałem.
Ale bardzo duzo daje do myslenia test nosql sprzed pół roku po miesiącu ukazał sie ten sam test pod realcyjną bazą gdzie osiagnięto podobne wyniki. Jedyny speed nierelacyjnych był na załadowaniu klastra. Morał da się .

Telekomy i nierelacyjne bazy? Też mi “ciekawostka”…

TP SA i PTK Centertel (Orange) używają prawie wyłącznie Oracle DB (sporadycznie PostgreSQL, MS SQL Server, DB2). Dla Data Mining / OLAP używa się Teradata lub nakładkę nad Oracle: Business Objects.
Z tego co pamiętam ERA GSM i Netia też jadą na Oracle DB.

W Orange nawet dispatcher SMS działa na Oracle DB.

Ja tego nie czytałem, ja to wiem, bo przy tym pracowałem.

Oracle DB spisuje się naprawdę bardzo dobrze.
Co niby więcej może dać jakaś nierelacyjna baza danych niż najlepsza relacyjna, w której do konkretnego zastosowania można przecież nie użyć relacji?

Czy mówimy to o bazach hierarchicznych czy o obiektowych czy może o prostych mechanizmach w stylu Berkeley DB?
A może chodzi o używanie na masową skalę WebSphere MQ, który siłą rzeczy ma własną nierelacyjną bazę.

@abcman: “eventually consistent” czy “consistent” jest kwestią ortogonalną w stosunku do użytego modelu danych (relacyjny, obiektowy, hierarchiczny itp). Eventually consistent masz np. w klastrach z replikacją asynchroniczną.

Do tego wielu chyba myli No-SQL z nierelacyjnymi bazami – a to są dwa różne kryteria. Key-value store, który jest jednym z modeli przyjętych w bazach No-SQL, jest jak najbardziej relacyjną bazą danych. Tyle że jest inny interfejs i kwestie powiązań między relacjami są przerzucone na aplikację. Co ma pewne wady i zalety.

Jak napisał borizm, problem leży zupełnie gdzie indziej. Ponieważ RDBMSy starają się być systemami uniwersalnymi, to ich stopień komplikacji jest na tyle duży, że większość adminów nie potrafi powiedzieć, jak dokładnie baza działa w środku i trudno przewidzieć jak pewne decyzje wpłyną na skalowalność i wydajność. Zresztą nawet się tego nie uczy na uczelniach wyższych. Również stworzenie dobrego RDBMSa jest dużo trudniejsze niż bazki typu No-SQL. Rozproszoną hashmapę to pierwszy lepszy student na zaliczenie naskrobie (podobnie jak framework webowy albo CMS – stąd mamy ich tyle, zarówno bazek No-SQL jak i frameworków webowych i CMSów).

No i jest jeszcze taka kwestia, że nie wszyscy potrzebują full-wypas systemu bazodanowego – w wielu sytuacjach rozproszona hashmapa jest właśnie wystarczającym rozwiązaniem.

Jeszcze jedno:

“mitów typu (join jest szybszy od IN) ”

ak47: nie sądzę, żeby to był mit, o ile mówimy o optymalizatorze pokroju Oracla, a nie MySQLa. Z tego co się orientuję, to Oracle przepisuje podzapytania z IN na SEMI-JOIN domyślnie (SEMI-JOIN jest zawsze co najmniej tak samo szybkie jak IN, o ile da się przepisać), jeszcze przed optymalizacją kolejności złączeń. Pisałeś to w kontekście Oracla, czy jakiejś innej bazy?

@królik
“mimo że jest to zależne od ilości wartości w złączeniu”
którego słowa nie rozumiesz?
czasem nie ma sensu robic joina z wielka tabela jeśli wiemy że podzapytanie z niej zwróci nami kilka wartości.

@ak47: rozumiem treść, ale się nie zgadzam z tym, że jest to zależne od liczności łączonych relacji, w taki sposób jak piszesz. Zapominasz, że planner ma do wyboru kilka algorytmów wykonywania złączeń. Jeden z nich – Nested Loops Join przekłada się na identyczny ciąg operacji w warstwie wykonawczej, co wykonanie podzapytania. W przypadku, który opisujesz po prostu ten algorytm zostanie użyty i nie będzie różnicy.

W wielu innych przypadkach takie przepisanie daje szanse na Sort Merge Join / Hash Join / Block Nested Loops, co jest wydajniejsze.

Oczywiście może zdarzyć się sytuacja, że planner się pomyli i wybierze zły algorytm złączenia, ale to jest raczej wyjątkowa sytuacja (i wtedy przyjrzałbym się statystykom, ewentualnie dał mu hinta).

@krolik
chodzi o to że mając złączenie 5 tabelek gdy wiemy że złaczenie 3 z nich przy warunku where dadzą na kilka wartości to często lepiej jest zrobić podzapytanie, jako warunek where złączenia 2 tabel. Co do planerów to jest tylko automat, więc może mu nie wyjść …

@ak47: masz rację, że automatowi może nie wyjść*, jednak automat ma tę przewagę, że potrafi dostosowywać plany do aktualnych danych w bazie (o ile admin nie jest debilem i włączył tworzenie histogramów i innych statystyk). Jak zahardkodujesz ręcznie plan zapytania (np. za pomocą hintów albo przez złożone podzapytanie którego QRW nie potrafi przepisać), to tej elastyczności juz nie ma. I system, który działał dobrze na początku, gdy było mało danych, po roku zaczyna mulić, bo nagle z 10 iteracji podzapytania zrobiło się 10000.

*) w dobie optymalizatorów samouczących się, to jest coraz rzadsza rzadkość

@królik
czasem trzeba być mądrzejszym niż automat, chodzi mi sytuacje gdzie zawsze niezależnie od przyrostu danych będzie kilka rekordów w wyniku.

Jeśli zawsze będzie tylko kilka rekordów, to trochę dziwne by było, żeby optymalizator tego nie zauważył. Uczący się optymalizator, taki jak w DB/2, nie “głupi” jak w PgSql

Tak, już minusujecie, bo myślicie, że skrytykowałem PgSQL.

A chodzi tylko o to, że optymalizatory można podzielić na uczące się i na nieuczące się. Nieuczące się są po prostu “głupie” – zawsze stosują się do wzorów wbudowanych w program i mogą tysiąć razy wygenerować ten sam zły plan. Taki optymalizator jest m.in. w MySQL, PostgreSQL i SQLite.

Natomiast uczące się, potrafią “wyciągać wnioski” ze swoich błędów. DB/2 umie np. przerwać w połowie wykonywanie zapytania, jak się zorientuje, że źle oszacowało krotność złączenia, powrócić do optymalizacji tym razem z nowymi danymi o krotności i znaleźć lepszy plan. Informacje te są wykorzystywane później dla następnych zapytań.

@królik
jedni nie wiedzą o czym mówisz drudzy uważają że zealocisz więc daj se na wstrzymanie

Racja.
Ale o tym umieraniu RDBMSów to słyszałem już na początku lat 90-tych. Wtedy miały być wyparte przez bazy obiektowe i logiczne, czy jakoś tak.

Bzdura – tam, gdzie relacyjność nie jest potrzebna, POWSZECHNIE stosowana jest np. BerkeleyDB.

@Królik – załóżmy, że mamy zrobić system, który bardzo wiele wymaga od bazy danych. I jest to system obiektowy (napisany np. w PHP5 albo w Javie). To jak byś wybrał:
a) RDBMS z ORM,
b) non-RDMS obiektowy?
Umieranie RDDMS jest długie, ale ludzie robiący duże systemy spodziewali się tego umierania ze względu na kłopoty wydajnościowe ORM-ów.

Wybrałbym dobry RDBMS z ORMem.

Po prostu dobre RDBMSy są lata przed dobrymi ODBMSami, jeśli chodzi o wydajność. Dobrze skonfigurowany ORM wspomagany lekko procedurami składowanymi wydajności nie szkodzi.

Problem z wydajnością nie leży w samym ORMie, a w modelu obiektowym. W modelu obiektowym nie możesz wyciągnąć z bazy ćwierć obiektu. W modelu obiektowym również sposób pracy z obiektami jest inny – zwykle wyciąga się jakiś obiekt, a później przechodzi po referencjach do innych obiektów. Takie łażenie po referencjach jest niezłe bo wygodne i wydajne, gdy wszystko siedzi w RAM, ale tragiczne gdy większość danych jest na dysku.
Weź wywal RAM z kompa i zobacz jak szybko chodzą “obiektowe” programy jak muszą swapować.

W modelu relacyjnym podejście jest inne – zapytać od razu o potrzebne dane i dostać wszystko na raz.
W przypadku ORMów mogę robić takie obejścia i nadal korzystać z bazy w nieobiektowy sposób zwiększając wydajność. Nawet mogę zejść do SQLa, jesli zajdzie taka konieczność.

Zresztą ODBMS to co to jest w praktyce? RDBMS z ORMem, tyle że ten ORM siedzi sobie wewnątrz tej samej paczki zwanej systemem baz danych i jest lepiej zintegrowany.

W którym miejscu się PostgreSQL skaluje na *** wiele maszyn ***?
Gdzie są:
1. sharding / partycjonowanie poziome,
2. replikacja master-master
3. replikacja master-slave (warm-standby się nie liczy, bo to nie to samo)
4. obsługa baz rozproszonych (federacyjnych)

BTW: gotar w tej kwestii ostanio chyba jakiś research robił…

ad 1. pgpool2 (w kontekscie wielu maszyn) partycjonowanie w kontekscie jednej maszyny też istnieje
ad 2. bucardo, z darmowych, są także płatne rozszerzenia
ad 3. slony
ad 4. nie slyszałem o takich rozszerzeniach ale schematy są, two fase commit też jest więc co za problem?

ad 1. ma “single point of failure” jakim jest sam demon pgpool i bardzo długą listę “restrictions”. Poza tym dokumentacja do shardingu jest napisana niegramatycznym angielskim, którego nie sposób zrozumieć. Skoro nie potrafią nawet dokumentacji poprawnie napisać, to skąd mam mieć gwarancję, że na produkcji nie rozwali to mi danych?

ad 2: niech będzie
ad 3: hack na triggerach, ale niech będzie
ad 4: czyli nie ma

@ak47: to wszystko są protezy, wybacz ale nie będę eksperymentował na produkcji zestawem, który w całości nie jest dostatecznie przetestowany (bo nie jest używany, bo nikt mi nie da gwarancji czy supportu, ot co).

bucardo – skrypt w perlu, slony – zestaw triggerów, tak na prawdę tylko w pgpool-II mogę pokładać jakąś wiarę, że nie wyśle mi danych w kosmos, ale nim samym zbytnio nie poskaluję.

A w samym silniku też mocne ograniczenia – wczoraj pół dnia walczyłem z zapisami hint bits przy odczycie (w systemie, o którym wspomniałem niżej, gdzie tak na prawdę nie jest mi potrzebna baza relacyjna, a tablica jest INSERT/READ-only, więc nie ma żadnych starych tupli, nie ma też problemu jak jakieś dane by się zgubiły, bo to tylko statystyki i monitoring). Wcześniej do tej samej bazy musiałem stworzyć ręcznie 16 indeksów, każdy ma obecnie po 15 MB i będę musiał je przerobić na 256 – znowu ręcznie, bo o ile nawet autopartycjonowanie wejdzie do 8.5, to bez hashowania (a już sobie wyobraziłem tworzenie 256 dziedziczonych tabel z rulami i triggerami do obsługi tego, dlatego spartycjonowałem sam index). Brak covering index też nie jest zaletą.
Z powyższego jedynie problem pierwszy ‘rozwiązałem’, wpisując do crona ’select count(*) from table where date>now()-’2 days’::inverval’…

Z rzeczy trywialnych – nie da się przestawić kolejności kolumn. Ta z pozoru zbędna cecha jest przydatna, gdy tworzy się tabele z historią zminan – tabela docelowa ma mieć o 1 kolumnę więcej, niż źródłowa (z datą modyfikacji, ustaloną na now()), a trigger do przeniesienia postać ‘INSERT INTO ‘hist_’||TG_ARGV[0] VALUES(OLD.*)’ – co się posypie od razu po dodaniu dowolnej kolumny, gdyż w tabeli pierwotnej wskoczy na miejsce N, natomiast w tabeli z historią zmian na N+1 (za dodatkową kolumnę z czasem).

Każdy chyba kto pracuje z bazami prowadzi jakiś indeks ograniczeń – mi już brakowało przekazywania NEW do funkcji, ustalania kolejności w UPDATE (co ma znaczenie przy indeksach UNIQUE), ustalania defaulta na wartość z innej kolumny no i wreszcie brak możliwości sortowania po wyrażeniu przy UNION.

“Brak covering index też nie jest zaletą.”

Nawet jest bardzo dużą wadą.Dopóki tego nie zrobią, nie mają szans mierzyć się wydajnością z Oraclem.

Z tego co jednak było dyskutowane na listach dyskusyjnych postgresa, to szanse, że to się kiedyś zmieni są bliskie 0. Musieliby przebudować sposób zarządzania transakcjami i sposób trzymania indeksów. Indeksy nic nie wiedzą o tym, które rekordy są widoczne dla bieżącej transakcji, a które nie. Modyfikacje samego plannera w porównaniu z tym to już pikuś.

@gotar
możesz zapłacić za mamothdb czy enterpricedb za supprcik i kilka dodaków. Na slonym można zrobić bardzo dużo jeśli masz sporo więcej odczytów niż zapisów, Robi się kilkopoziomowe drzewko i można naprawdę spory ruch przemielić.
pierwszej części twojej wypowiedzi nie rozumiem. Index 15MB ? coś masz tam mało danych … 16 indeksów? ile z nich wykorzystujesz? ile z nich dało by się zmergować do indeksów wielokolumnowych?
256 tabel dziedziczących? Checki są kosztowne więc przesadzanie z ilością tabel dziedziczących nie wyjdzie ci na dobre… W dodatku partycjonowanie ma sens przy tabelach powyżej ~40GB gdzie partycja ma minimum ~2GB a większość zapytań mieści się tak naprawdę tylko w jednym/dwóch setach.
Nie będzie postgresa 8.5 będzie 9.0.
druga część:
Tak się objawia stosowanie gwiazdek w zapytaniach … z ustawianiem kolejności kolumn spotkałem się tylko progressie. Jak sobie zrobisz rule z gwiazdką to i tak ci to postgres zamieni na konkretne wartości.
część trzecia
new w funkcji ? funkcja trigger?
kolejność czego w update?
default na podstawie innej kolumny? niepotrzebna duplikacja danych załatwia się to widokiem aby dostać piękną “rozszerzona tabelkę” lub brzydko używając ruli/trigerów i mieć hard write w tabeli.
sortowanie union (częsci uni)to trochę bardziej skomplikowane niż ci się wydaje. Sortowanie to warstwa wizualizacji danych a tych cząstek danych nie widzisz tak naprawdę. Do obejścia funkcją.
Jeśli możesz wejdź na #python.pl irc.freenode.net to pogadamy “na żywo”

@ak47 – z płaceniem to jest tak, że ten kto wykłada gotówkę chce wiedzieć na co, a z dwóch jakie wymieniłeś sam znam tylko EnterpriseDB. Zatem (pomijając już nawet kwestię dostępności profesjonalnego supportu w Polsce) gdy pojawiają się pieniądze, zwykle ktoś (projektant systemu, wdrożeniowiec, whatever) wspomni o tym Oraclu. W moim np. przypadku Oracle i tak miał być, bo był potrzebny do innego zamkniętego systemu, ale że go jednak nie będzie, mam jeszcze nieco możliwości szukania rozwiązań postgresowych.

Proporcji odczyt/zapis: w systemach, o których pisałem wcześniej, mam 99,99% zapisów (w tym, który obecnie jest tworzony, nie mam na razie pojęcia, jest w końcowym etapie projektowym, przed optymalizacjami).

Mam 16 indeksów częściowych obejmujących jedną kolumnę (macaddr). Gdy index był jeden i miał 200+MB system był nieużywalny. Teraz wiem, że duży wpływ na to miały hint bits, ale nawet po ich zapisaniu przy obecnych 15MB indeksach odczyt (zaznaczam: korzystam z jednego z nich na raz) trwa kilka sekund (wcześniej było ok. 30). A tabela duża nie jest – nieco ponad 18,5M rekordów, każdy średnio do 100 bajtów danych (timestamp, macaddr, inet, varchar(8), varchar(16), varchar(16), varchar(192), varchar(64), int4). Do tego 8 indeksów częściowych na inet oraz po jednym na int oraz timestamp (czyli zindeksowane jest wszystko ≠ varchar). Partycjonowanie tutaj ma oszczędzić jedynie na I/O, bo CPU się raczej nudzi. Na dobrą sprawę indeksy obejmują połowę danych z tabeli… Indeksy rozdzielane są na podstawie konkretnego oktetu (i tu przydałaby mi się automatyka stosująca hash), a ponadto musiałem dopasować zapytania tak, aby tego indeksu używały (postgresowy planner słabo sobie radzi z wyłapywaniem zależności nie podanych explicite i potrafi pominąć pasujący index).
Mam jeszcze identyczną bazę, ale o rząd wielkości większą – chyba 150GB wyszło w momencie, gdy ją odłączyłem.

Tak się objawia stosowanie gwiazdek w zapytaniach

Nie mam ich w zapytaniach, chciałem mieć jedną funkcję zakładaną jako trigger na wybranych tabelach no i niestety musi być znacznie bardziej skomplikowana niż ta, którą podałem (miało oczywiście być TG_RELNAME).

new w funkcji ? funkcja trigger?

Zbyt duży skrót myślowy – chodzi o sytuację, w której na tabeli X chcę założyć trigger do sprawdzania wartości z kolumny A, natomiast na tabeli Y z kolumny B; czyli muszę do triggera przekazać nazwę kolumny do sprawdzenia. I tutaj wydaje mi się, że próbowałem użyć NEW.TG_ARGV[x] i jeśli dobrze pamiętam (pisałem to w okolicach 7.1), to był z tym problem, ale rozwiązałem na około.

kolejność czego w update?

Właśnie samego update: update table set unique_column=unique_column+1.

default na podstawie innej kolumny? niepotrzebna duplikacja danych załatwia się to widokiem aby dostać piękną “rozszerzona tabelkę” lub brzydko używając ruli/trigerów i mieć hard write w tabeli.

To nie jest niepotrzebna duplikacja, tylko zwyczajna domyślna wartość. Nie rozumiem, w czym podanie konkretnej wartości czy funkcji (jak now()) miałoby być gorsze od wskazania, że domyślnie ma być tyle, co w innej kolumnie. Wiem, jak to się obchodzi – i właśnie to jest brzydkie, bo zamiast prostego SET DEFAULT muszę pisać funkcję. Równie dobrze można postulować wywalenie wartości domyślnych (też można dopisać z ręki), CHECKi (co, nie da się sprawdzić funkcją?), klucze obce (no, też można odpytać wprost, czy nie psujemy zależności), a stąd prosta droga do pisania wszystkiego samemu w C.

sortowanie union (częsci uni)to trochę bardziej skomplikowane niż ci się wydaje. Sortowanie to warstwa wizualizacji danych a tych cząstek danych nie widzisz tak naprawdę. Do obejścia funkcją.

Rzecz w tym, że tam nie może być żadnego wyrażenia – nawet 1+1, nieodnoszącego się zupełnie do danych ‘zagubionych’ już pod spodem.

Może korzystając z okazji przedstawię osobno swój obecny NIErozwiązany problem z postgresem (bo pozostałe to jakimiś funkcjami czy dziwnymi hackami załatwiłem) – klasyczny ‘worek na dane’: tabela ok. 20M rekordów postaci

timestamp, macaddr, inet, int4, 5 varcharów (jeden z nich to tak na prawdę ENUM)

zapisywana dzień i noc (30k rekordów dobowo), odczytywana sporadycznie dla konkretnego macaddr lub inet (z rzadka enum, to można pominąć). Pytanie: co jest źle, co powinno być zindeksowane lub jakkolwiek zrobione prawidłowo, aby odczyt powiedzmy 100 ostatnich rekordów nie trwał 10 s?

Drugi problem, jaki mi wisiał, właśnie rozwiązałem, do trzech razy sztuka:)

wiesz pomaganie komuś pod takim artem nie ma większego sensu.
wejdź na irca pokaż kilka planów i zapytań to się pomyśli …

Postaram się wejść jak znajdę chwię wolnego czasu. Plan dla mnie wygląda OK, tylko I/O szaleje, ale może czegoś nie wiem.

Wychodzisz z założenia, że domena publiczna jest rozpoznawalna w Polsce. Moim zdaniem nie jest to tak proste.

Jest to problematyczne, ale domena publiczna jest rozpoznawalna, w szczególności należą do niej utwory nieobjęte prawami autorskimi (np. dokumenty urzędowe) oraz utwory, co do których ochrona wygasła (zazwyczaj 70 lat po śmierci autora).
http://www.ebib.info/2009/101/a.php?bednarek_tarkowski_szczepanska

Problematyczne jest natomiast zrzeczenie się majątkowych praw autorskich, czyli samodzielne przeniesienie utworu do domeny publicznej:
http://prawo.vagla.pl/node/7424

Public domain pozbawia autora kodu wszystkich praw

Nieprawda, tylko praw majątkowych.

czy kontekście polskiego ustawodawstwa istnieją prawa niezbywalne?

Wystarczy zajrzeć do ustawy o prawie autorskim i prawach pokrewnych, art. 16 (autorskie prawa osobiste). Nie cytuję, łatwo samemu wygooglać.

@blinkkin komplikujesz:

- domena publiczna w PL nie obowiązuje (w uproszczeniu)
- licencja sqlite to w PL licencja niewyłączna typu “róbta co chceta”
- prawa autorskie osobiste są niezbywalne.. ale to tego przypadku nie dotyczy (co ciekawe w wielu krajach, w tym anglosaskich nie ma odpowiednika polskich praw autorskich)
- występowanie o glejt przez korporacje to specyfika prawa USA i.. korporacji. Nawet jeśli nie trzeba czegoś robić to się to robi, by mieć potwierdzenie na papierze (lub elektroniczne) na potrzeby audytu wewnętrznego i innych kontroli.