6-DAL finished

sources/40-web2py-czech-translation-in-progress/06.markmin

@@ -3276,37 +3276,36 @@ db =DAL(..., driver_args={}, adapter_args={})
 
 #### Specifické odchylky a problémy různých databázových strojů
 
-**SQLite** does not support dropping and altering columns. That means that web2py migrations will work up to a point. If you delete a field from a table, the column will remain in the database but will be invisible to web2py. If you decide to reinstate the column, web2py will try re-create it and fail. In this case you must set ``fake_migrate=True`` so that metadata is rebuilt without attempting to add the column again. Also, for the same reason, **SQLite** is not aware of any change of column type. If you insert a number in a string field, it will be stored as string. If you later change the model and replace the type "string" with type "integer", SQLite will continue to keep the number as a string and this may cause problem when you try to extract the data.
+**SQLite** nepodporuje zrušení a změny sloupců. Znamená to, že Web2py migrace nebudou pracovat ideálně. Když zrušíte pole (sloupec) tabulky, sloupec zůstane v databázi, ale nebude nadále viditelný pro Web2py. Jestliže se později rozhodnete stejný sloupec znovu přidat, Web2py se o to pokusí a havaruje. V tomto případě musíte nastavit ``fake_migrate=True``, aby se metadata aktualizovala bez pokusu sloupec skutečně fyzicky přidat. Ze stejného důvodu **SQLite** dělají potíže změny typu sloupců. Vložíte-li číslo do pole typu string (řetězec), uloží se jako řetězec. Když model později změníte a nahradíte typ "string" typem "integer", v SQLite zůstanou i nadále uloženy řetězce a to způsobí problém při získávání dat z databáze.
 
-**MySQL** does not support multiple ALTER TABLE within a single transaction. This means that any migration process is broken into multiple commits. If something happens that causes a failure it is possible to break a migration (the web2py metadata are no longer in sync with the actual table structure in the database). This is unfortunate but it can be prevented (migrate one table at the time) or it can be fixed a posteriori (revert the web2py model to what corresponds to the table structure in database, set ``fake_migrate=True`` and after the metadata has been rebuilt, set ``fake_migrate=False`` and migrate the table again).
+**MySQL** nepodporuje více příkazů ALTER TABLE v jedné transakci. Znamená to, že každý (složitější) migrační proces musí být rozdělen do více commitů. Jestliže nastane nějaká chyba, může dojít k poškození mechanismu migrace (Web2py metadata přestanou odpovídat aktuální struktuře tabulky v databázi). Tomuto problému zabráníte nejlépe tak, že budete migrovat vždy jednu tabulku v jednotlivém kroku. Nebo je možné opravit problém dodatečně, pokud vznikne (vrátit Web2py model do stavu, který odpovídá skutečné struktuře tabulek v databázi, nastavit ``fake_migrate=True``, spustit aplikaci (nebo appadmin) pro přebudování metadat, vrátit na ``fake_migrate=False`` a opakovat migraci).
 
-**Google SQL** has the same problems as MySQL and more. In particular table metadata itself must be stored in the database in a table that is not migrated by web2py. This is because Google App Engine has a read-only file system. Web2py migrations in Google:SQL combined with the MySQL issue described above can result in metadata corruption. Again, this can be prevented (by migrating the table at once and then setting migrate=False so that the metadata table is not accessed any more) or it can fixed a posteriori (by accessing the database using the Google dashboard and deleting any corrupted entry from the table called ``web2py_filesystem``.
+**Google SQL** má stejný problém jako MySQL a další navíc. Konkrétně samotná metadata musí být uložena v databázi, do tabulky, kterou Web2py nemigruje. To proto, že Google App Engine má read-only souborový systém. Web2py migrace nad Google:SQL, kombinovaná s problémem, popsaným právě u MySQL, může vést k poškození metadat. Znova: nejlépe tomu zabráníte migrací postupně po jednotlivých tabulkách a nakonec nastavením migrate=False, čímž nebudou metadata už nadále používána. Nebo je možné opravit problém dodatečně (přístupem k databázi z Google dashboard a smazáním poškozených položek z tabulky se jménem ``web2py_filesystem``.
 
 ``limitby``:inxx
-**MSSQL** does not support the SQL OFFSET keyword. Therefore the database cannot do pagination. When doing a ``limitby=(a,b)`` web2py will fetch the first ``b`` rows and discard the first ``a``. This may result in a considerable overhead when compared with other database engines.
+**MSSQL** nepodporuje SQL frázi OFFSET. Databáze tedy nemůže správně stránkovat. Když zadáte ``limitby=(a,b)``, Web2py v skutečnosti získá prních ``b`` záznamů a pak z nich prvních ``a`` záznamů zahodí. Může to způsobit značné zpomalení ve srovnání s provozem jiných databázových strojů.
 
-**Oracle** also does not support pagination. It does not support neither the OFFSET nor the LIMIT keywords. Web2py achieves pagination by translating a ``db(...).select(limitby=(a,b))`` into a complex three-way nested select (as suggested by official Oracle documentation). This works for simple select but may break for complex selects involving aliased fields and or joins.
+Ani **Oracle** nepodporuje stránkování. Nezná nejen frázi OFFSET, ale ani LIMIT. Web2py dosáhne stránkování přeložením ``db(...).select(limitby=(a,b))`` na složitý třícestný nested select (výběr s podvýběrem), jak radí oficiální dokumentace Oracle. To uspokojivě pracuje pro jednodušší selecty, ale může havarovat pro složité selecty s aliasovanými poli nebo joiny.
 
-**MSSQL** has problems with circular references in tables that have ONDELETE CASCADE. This is an MSSQL bug and you work around it by setting the ondelete attribute for all reference fields to "NO ACTION". You can also do it once and for all before you define tables:
+**MSSQL** má problém při cirkulárních odkazech mezi tabulkami, kde klíče mají nastaveno ONDELETE CASCADE. Je to bug MSSQL a pokud na něj narazíte, zabráníte mu nastavením ondelete atributu všech cizích klíčů na "NO ACTION". Můžete to také udělat najednou ještě předtím, než definujete tabulky:
 
 ``
 db = DAL('mssql://....')
-for key in ['reference','reference FK']:
-    db._adapter.types[key]=db._adapter.types[key].replace(
+for key in ['reference', 'reference FK']:
+    db._adapter.types[key] = db._adapter.types[key].replace(
         '%(on_delete_action)s','NO ACTION')
 ``:code
 
-**MSSQL** also has problems with arguments passed to the DISTINCT keyword and therefore
- while this works,
+**MSSQL** má problém i s argumentem, předaným do fráze DISTINCT, a tak zatímco toto pracuje správně:
 
 ``
 db(query).select(distinct=True)
 ``
 
-this does not
+toto nelze použít:
 
 ``
 db(query).select(distinct=db.mytable.myfield)
 ``
 
-**Google NoSQL (Datastore)** does not allow joins, left joins, aggregates, expression, OR involving more than one table, the ‘like’ operator searches in "text" fields. Transactions are limited and not provided automatically by web2py (you need to use the Google API ``run_in_transaction`` which you can look up in the Google App Engine documentation online). Google also limits the number of records you can retrieve in each one query (1000 at the time of writing). On the Google datastore record IDs are integer but they are not sequential. While on SQL the "list:string" type is mapped into a "text" type, on the Google Datastore it is mapped into a ``ListStringProperty``. Similarly "list:integer" and "list:reference" are mapped into "ListProperty". This makes searches for content inside these fields types are more efficient on Google NoSQL than on SQL databases.
+**Google NoSQL (Datastore)** nepodporuje joiny, left joiny, agregace, výrazy, zahrnutí více než jedné tabulky, ‘like’ operátor nepracuje nad "text" poli. Transakce jsou omezené a nejsou automaticky řízeny z Web2py (místo toho potřebujete explicitně volat Google API ``run_in_transaction``, podrobnosti najdete v Google App Engine dokumentaci online). Google také omezuje počet záznamů, které vrátí jednotlivý dotaz (v době psaní textu platil limit 1000 záznamů). ID záznamů jsou sice integer, ale nejsou přidělována ve vzestupné sekvenci. Zatímco na SQL je typ "list:string" mapován na "text" typ, na Google Datastore je mapován na ``ListStringProperty``. Podobně "list:integer" a "list:reference" jsou mapovány na "ListProperty". Tím je prohledávání obsahu těchto polí na Google NoSQL efektivnější než na SQL databázích.