Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commit3f54071

Browse files
committed
Update Russian FAQ.
Victor Vislobokov
1 parent6bc4e36 commit3f54071

File tree

2 files changed

+89
-22
lines changed

2 files changed

+89
-22
lines changed

‎doc/FAQ_russian

Lines changed: 43 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -1,12 +1,12 @@
11

22
Otvety na chasto zadavaemye voprosy po PostgreSQL
33

4-
Data poslednego obnovleniya:Ponedel'nik 30 maya 09:11:03 EDT 2005
4+
Data poslednego obnovleniya:Pyatnica 16 sentyabrya 14:07:22 EDT 2005
55

66
Anglijskij variant soprovozhdaet: Bryus Mom'yan (Bruce Momjian)
77
(pgman@candle.pha.pa.us)
88

9-
Pereviol na russkij: Viktor Vislobokov (corochoone@perm.ru)
9+
Pereviol na russkij: Viktor Vislobokov (admin@linuxshare.ru)
1010

1111
Samuyu svezhuyu anglijskuyu versiyu dokumenta mozhno najti na
1212
http://www.PostgreSQL.org/files/documentation/faqs/FAQ.html.
@@ -94,14 +94,17 @@
9494
suschestvuet", kogda obraschayuts' k vremennym tablicam v funkciyah
9595
PL/PgSQL?
9696
4.20) Kakie est' resheniya dlya replikacii?
97+
4.21) Pochemu imena tablicy i kolonok ne raspoznayutsya v v moiom
98+
zaprose?
9799
_________________________________________________________________
98100

99101
Obschie voprosy
100102

101103
1.1) CHto takoe PostgreSQL? Kak proiznositsya `eto nazvanie?
102104

103105
PostgreSQL proiznositsya Post-Gres-Q-L (Post-Gres-K'yu-`El), takzhe
104-
chasto govoryat prosto Postgres.
106+
inogda govoryat prosto Postgres. Vy mozhete uslyshat' kak `eto
107+
proiznositsya s pomosch'yu audiofajla, kotoryj dostupen v formate MP3.
105108

106109
PostgreSQL - `eto ob"ektno-relyacionnaya sistema upravleniya bazami
107110
dannyh (SUBD), kotoraya imeet tradicionnye vozmozhnosti kommercheskih
@@ -205,7 +208,7 @@
205208

206209
1.7) Kakaya poslednyaya versiya?
207210

208-
Poslednij vypusk PostgreSQL - `eto versiya 8.0.2
211+
Poslednij vypusk PostgreSQL - `eto versiya 8.0.3
209212

210213
My planiruem vypuskat' novye starshie versii kazhdyj god, a mladshie
211214
versii kazhdye neskol'ko mesyacev.
@@ -535,6 +538,13 @@
535538
byt' uvelicheny v chetyre raza, esli razmer bloka po umolchaniyu budet
536539
uvelichen do 32k.
537540

541+
Suschestvuet ogranichenie, po kotoromu indeksy ne mogut sozdavat'sya
542+
dlya kolonok dlinnee chem 2,000 simvolov. K schast'yu takie indeksy
543+
vryad li dejstvitel'no komu-to nuzhny. Unikal'nost' garantiruetsya
544+
nailuchim obrazom, s pomosch'yu funkcional'nogo indeksa iz h`esha MD5
545+
dlinnoj kolonki, a polnotekstovoe indeksirovanie pozvolyaet iskat'
546+
slova vnutri kolonki.
547+
538548
4.5) Kak mnogo diskovogo prostranstva v baze dannyh nuzhno dlya sohraneniya
539549
dannyh iz obychnogo tekstovogo fajla?
540550

@@ -546,23 +556,23 @@
546556
srednem, sostavlyaet 20 bajt. Razmer prostogo fajla sostavit 2.8 MB.
547557
Razmer bazy PostgreSQL, soderzhaschej `eti zhe dannye sostavit
548558
priblizitel'no 6.4 MB iz kotoryh:
549-
32 bajt: na kazhdyj zagolovok stroki v tablice (priblizitel'no)
559+
28 bajt: na kazhdyj zagolovok stroki v tablice (priblizitel'no)
550560
+ 24 bajta: odno pole s celochislennym tipom i odno tekstovoe pole
551561
+ 4 bajta: ukazatel' na stranice dlya vsej tablichnoj stroki
552562
----------------------------------------
553-
60 bajt na stroku v tablice
563+
56 bajt na stroku v tablice
554564

555565
Razmer stranicy dannyh v PostgreSQL sostavlyaet 8192 bajt (8 KB), tak chto:
556566

557567
8192 bajt na stranicu
558-
--------------------- =136 strok v tablice na stranicu BD (okruglionno)
559-
60 bajt na stroku v tablice
568+
--------------------- =146 strok v tablice na stranicu BD (okruglionno)
569+
56 bajt na stroku v tablice
560570

561571
100000 strok dannyh
562-
----------------------- =735 stranic v BD (okruglionno)
563-
128 strok v tablice na stranicu
572+
----------------------- =685 stranic v BD (okruglionno)
573+
146 strok v tablice na stranicu
564574

565-
735 stranic BD * 8192 bajt na stranicu =6,021,120 bajt (6 MB)
575+
685 stranic BD * 8192 bajt na stranicu =5,611,520 bajt (5.6 MB)
566576

567577
Indeksy ne trebuyut tak mnogo, no poskol'ku oni sozdayutsya dlya
568578
bol'shogo kolichestva dannyh, oni takzhe mogut byt' veliki.
@@ -650,6 +660,13 @@
650660
esli vy sozdadite indeks vyrazheniya, on budet ispol'zovan:
651661
CREATE INDEX tabindex ON tab (lower(col));
652662

663+
Esli vysheukazannyj indeks sozdaiotsya kak UNIQUE, to kolonka, dlya
664+
kotoroj on sozdaiotsya mozhet hranit' simvoly i v verhnem, i v nizhnem
665+
registre, indes ne mozhet imet' identichnyh znachenij, kotorye
666+
otlichayutsya tol'ko registrom. CHtoby v kolonke mozhno bylo hranit'
667+
simvoly tol'ko v opredelionnom registre, ispol'zujte ogranichenie
668+
CHECK ili proverku cherez trigger.
669+
653670
4.9) Kak mne opredelit', chto znachenie polya ravno NULL v kakom-libo
654671
zaprose? Mogu ya otsortirovat' polya NULL ili net?
655672

@@ -869,3 +886,18 @@ CREATE TABLE test (x int, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );
869886
neobhodima sinhronizaciya izmenenij mezhdu neskol'kimi serverami.
870887
Naibolee populyarnym resheniem dlya takoj replikacii v PostgreSQL
871888
yavlyaetsya Pgcluster.
889+
890+
4.21) Pochemu imena tablicy i kolonok ne raspoznayutsya v v moiom zaprose?
891+
892+
Naibolee chasto `eto proishodit iz-za ispol'zovaniya dvojnyh kavychek
893+
v imeni tablicy ili kolonki pri sozdanii tablicy. Pri ispol'zovanii
894+
dvojnyh kavychek, imya tablicy i kolonki (kotorye nazyvayut
895+
identifikatorami) sohranyayutsya v registro-zavisimom vide; `eto
896+
oznachaet, chto vy dolzhny ispol'zovat' dvojnye kavychki, kogda
897+
ukazyvaete `eti imena v zaprose. Nekotorye interfejsy, takie kak
898+
pgAdmin, vo vremya sozdaniya tablicy dobavlyayut dvojnye kavychki
899+
avtomaticheski. Takim obrazom, chtoby identifikatory raspoznavalis' vy
900+
dolzhny sledovat' odnomu iz sleduyuschih pravil:
901+
* Izbegat' ispol'zovaniya dvojnyh kavychek pri sozdanii tablic
902+
* Ispol'zovat' v identifikatorah tol'ko simvoly nizhnego registra
903+
* Ispol'zovat' dvojnye kavychki dlya identifikatorov v zaprosah

‎doc/src/FAQ/FAQ_russian.html

Lines changed: 46 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -12,13 +12,13 @@
1212
<BODYbgcolor="#ffffff"text="#000000"link="#ff0000"vlink="#a00000"alink="#0000ff">
1313
<H1>Ответы на часто задаваемые вопросы по PostgreSQL</H1>
1414

15-
<P>Дата последнего обновления:Понедельник 30 мая 09:11:03 EDT 2005</P>
15+
<P>Дата последнего обновления:Пятница 16 сентября 14:07:22 EDT 2005</P>
1616

1717
<P>Английский вариант сопровождает: Брюс Момьян (Bruce Momjian) (<Ahref=
1818
"mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR>
1919
</P>
2020
<P>Перевёл на русский: Виктор Вислобоков (<Ahref=
21-
"mailto:corochoone@perm.ru">corochoone@perm.ru</A>)<BR>
21+
"mailto:admin@linuxshare.ru">admin@linuxshare.ru</A>)<BR>
2222
</P>
2323

2424
<P>Самую свежую английскую версию документа можно найти на
@@ -117,6 +117,8 @@
117117
<Ahref="#4.19">4.19</A>) Почему я получаю ошибку "relation with OID ####
118118
не существует", когда обращаютсь к временным таблицам в функциях PL/PgSQL?<BR>
119119
<Ahref="#4.20">4.20</A>) Какие есть решения для репликации?<BR>
120+
<Ahref="#4.21">4.21</A>) Почему имена таблицы и колонок не
121+
распознаются в в моём запросе?<BR>
120122

121123
<HR>
122124

@@ -125,7 +127,10 @@
125127
<H3><Aname="1.1">1.1</A>) Что такое PostgreSQL? Как произносится это название?</H3>
126128

127129
<P>PostgreSQL произносится<I>Post-Gres-Q-L (Пост-Грес-Кью-Эл)</I>,
128-
также часто говорят просто<I>Postgres</I>.</P>
130+
также иногда говорят просто<I>Postgres</I>. Вы можете услышать как
131+
это произносится с помощью аудиофайла, который доступен в
132+
<Ahref="http://www.postgresql.org/files/postgresql.mp3">формате MP3</A>.
133+
</P>
129134

130135
<P>PostgreSQL - это объектно-реляционная система управления базами
131136
данных (СУБД), которая имеет традиционные возможности коммерческих
@@ -240,7 +245,7 @@
240245

241246
<H3><Aname="1.7">1.7</A>) Какая последняя версия?</H3>
242247

243-
<P>Последний выпуск PostgreSQL - это версия 8.0.2</P>
248+
<P>Последний выпуск PostgreSQL - это версия 8.0.3</P>
244249

245250
<P>Мы планируем выпускать новые старшие версии каждый год,
246251
а младшие версии каждые несколько месяцев.</P>
@@ -651,6 +656,12 @@
651656
<P>Максимальный размер таблицы и максимальное количество колонок
652657
могут быть увеличены в четыре раза, если размер блока по умолчанию будет
653658
увеличен до 32k.</P>
659+
660+
<P>Существует ограничение, по которому индексы не могут создаваться для
661+
колонок длиннее чем 2,000 символов. К счастью такие индексы вряд ли
662+
действительно кому-то нужны. Уникальность гарантируется наилучим образом,
663+
с помощью функционального индекса из хэша MD5 длинной колонки, а
664+
полнотекстовое индексирование позволяет искать слова внутри колонки.</P>
654665

655666
<H3><Aname="4.5">4.5</A>) Как много дискового пространства в базе данных
656667
нужно для сохранения данных из обычного текстового файла?</H3>
@@ -664,23 +675,23 @@
664675
Размер базы PostgreSQL, содержащей эти же данные составит приблизительно
665676
6.4 MB из которых:</P>
666677
<PRE>
667-
32 байт: на каждый заголовок строки в таблице (приблизительно)
678+
28 байт: на каждый заголовок строки в таблице (приблизительно)
668679
+ 24 байта: одно поле с целочисленным типом и одно текстовое поле
669680
+ 4 байта: указатель на странице для всей табличной строки
670681
----------------------------------------
671-
60 байт на строку в таблице
682+
56 байт на строку в таблице
672683

673684
Размер страницы данных в PostgreSQL составляет 8192 байт (8 KB), так что:
674685

675686
8192 байт на страницу
676-
--------------------- =136 строк в таблице на страницу БД (округлённо)
677-
60 байт на строку в таблице
687+
--------------------- =146 строк в таблице на страницу БД (округлённо)
688+
56 байт на строку в таблице
678689

679690
100000 строк данных
680-
----------------------- =735 страниц в БД (округлённо)
681-
128 строк в таблице на страницу
691+
----------------------- =685 страниц в БД (округлённо)
692+
146 строк в таблице на страницу
682693

683-
735 страниц БД * 8192 байт на страницу =6,021,120 байт (6 MB)
694+
685 страниц БД * 8192 байт на страницу =5,611,520 байт (5.6 MB)
684695
</PRE>
685696

686697
<P>Индексы не требуют так много, но поскольку они создаются для
@@ -781,6 +792,12 @@
781792
<PRE>
782793
CREATE INDEX tabindex ON tab (lower(col));
783794
</PRE>
795+
<P>Если вышеуказанный индекс создаётся как<SMALL>UNIQUE</SMALL>, то
796+
колонка, для которой он создаётся может хранить символы и в верхнем,
797+
и в нижнем регистре, индес не может иметь идентичных значений, которые
798+
отличаются только регистром. Чтобы в колонке можно было хранить символы
799+
только в определённом регистре, используйте ограничение
800+
<SMALL>CHECK</SMALL> или проверку через триггер.</P>
784801

785802
<H3><Aname="4.9">4.9</A>) Как мне определить, что значение поля равно
786803
<SMALL>NULL</SMALL> в каком-либо запросе? Могу я отсортировать поля
@@ -1071,5 +1088,23 @@
10711088
популярным решением для такой репликации в PostgreSQL является
10721089
<Ahref="http://pgfoundry.org/projects/pgcluster/">Pgcluster</A>.
10731090

1091+
<H3><Aname="4.21">4.21</A>) Почему имена таблицы и колонок не
1092+
распознаются в в моём запросе?</H3>
1093+
1094+
<P>Наиболее часто это происходит из-за использования двойных кавычек в
1095+
имени таблицы или колонки при создании таблицы. При использовании двойных
1096+
кавычек, имя таблицы и колонки (которые называют идентификаторами)
1097+
сохраняются в<Ahref="http://www.postgresql.org/docs/8.0/static/sql-syntax.html#SQL-SYNTAX-IDENTIFIERS">
1098+
регистро-зависимом виде</A>; это означает, что вы должны использовать
1099+
двойные кавычки, когда указываете эти имена в запросе. Некоторые
1100+
интерфейсы, такие как pgAdmin, во время создания таблицы добавляют
1101+
двойные кавычки автоматически. Таким образом, чтобы идентификаторы
1102+
распознавались вы должны следовать одному из следующих правил:
1103+
<UL>
1104+
<LI>Избегать использования двойных кавычек при создании таблиц</LI>
1105+
<LI>Использовать в идентификаторах только символы нижнего регистра</LI>
1106+
<LI>Использовать двойные кавычки для идентификаторов в запросах</LI>
1107+
</UL>
1108+
10741109
</BODY>
10751110
</HTML>

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp