Přejít na obsah

Doporučené příspěvky

Odesláno

Nevím zda ti to pomůže. Je to nápověda ACCESU. Já bych to líp vysvětlit nedovedl.

"Primární klíče

Význam systému relačních databází, jako je například aplikace Microsoft Access, spočívá ve schopnosti rychle vyhledat a spojit informace, které jsou uloženy v samostatných tabulkách. K vyhledávání, vkládání a prezentaci dat se využívají dotazy, formuláře a sestavy. Pro správnou funkci relační databáze je nezbytné, aby každá tabulka obsahovala pole, nebo skupinu polí, které jedinečným způsobem identifikují každý záznam tabulky. Takové pole nebo skupina polí se nazývá primární klíč tabulky. Po určení primárního klíče tabulky aplikace Microsoft Access zajistí, že do polí, která jsou součástí primárního klíče, nelze vložit žádné duplicitní hodnoty ani hodnoty Null."

 

Pole primární klíč nemůže obsahovat duplicity. Index se používá pro rychleší řazení a vyhledávání dat. Indexovat se dá buď s duplicitou nebo bez duplicity. Nejsem prohramátor ale vytvářím si aplikace pro vlastní potřebu, abych je nemusel draze kupovat:)

 

 

 

 

Odesláno
Zdravím,

 

jaký je rozdíl mezi primárním klíčem tabulky, primárním indexem a běžným indexem?

 

Hola, tak primární klíč tabulky slouží k jednoznačné identifikaci každého jediného záznamu v tabulce, např. u záznamu o osobě bude primární klíč rodné číslo, protože nikdo z lidí nemůže mít stejné RČ, ale kdokoliv se může jmenovat stejně, bydlet stejně apod. (viz záznam -> Jan | Novák | 6606065050 | U splavu 21 | Aš). Jinak primární klíč musí mít tři základní vlastnosti, aby mohl být PK - jedinečnost, neměnnost, nenulovou hodnotu (v tabulce smí být pouze jeden PK). (PK pak slouží k vytváření vazeb mezi tabulkami)

 

Indexování databáze se používá pro usnadnění a optimalizaci vyhledávání v databázi. Primární index je označení primárního klíče tabulky za index (tzn. daný sloupec - v našem případě rodné číslo bude sloužit k jednoznačnému vyhledávání), bežný index nebo taky sekundární index je označení sloupců za vedlejší klíče pro hledání. Tyto zaindexované záznamy se udržují v paměti a urychluje se tak hledání. Někdy se vytváří i nové fiktivní sloupce pro indexaci, odvozené od reálných záznamů.

 

Snad je to pochopitelné, jednoduše klíč slouží k jednoznačné identifikaci a indexování k optimalizaci vyhledávání.

Odesláno (upraveno)
Hola, tak primární klíč tabulky slouží k jednoznačné identifikaci každého jediného záznamu v tabulce, např. u záznamu o osobě bude primární klíč rodné číslo, protože nikdo z lidí nemůže mít stejné RČ, ale kdokoliv se může jmenovat stejně, bydlet stejně apod. (viz záznam -> Jan | Novák | 6606065050 | U splavu 21 | Aš). Jinak primární klíč musí mít tři základní vlastnosti, aby mohl být PK - jedinečnost, neměnnost, nenulovou hodnotu (v tabulce smí být pouze jeden PK). (PK pak slouží k vytváření vazeb mezi tabulkami)

 

Indexování databáze se používá pro usnadnění a optimalizaci vyhledávání v databázi. Primární index je označení primárního klíče tabulky za index (tzn. daný sloupec - v našem případě rodné číslo bude sloužit k jednoznačnému vyhledávání), bežný index nebo taky sekundární index je označení sloupců za vedlejší klíče pro hledání. Tyto zaindexované záznamy se udržují v paměti a urychluje se tak hledání. Někdy se vytváří i nové fiktivní sloupce pro indexaci, odvozené od reálných záznamů.

 

Snad je to pochopitelné, jednoduše klíč slouží k jednoznačné identifikaci a indexování k optimalizaci vyhledávání.

 

 

Děkuji moc všem za odpovědi. Mám tabulku, která má desítky tisíc řádků a v této tabulce sloupec, kde je číselníkem určena nějaká hodnota. Pak mám druhou tabulku, ve které mám desítky řádků - přiřazení slovních popisů jednotlivým hodnotám číselníku. Předpokládám, že bych měl u té velké tabulky na daný sloupec nastavit index (+ nastavit primární klíč na na sloupec, který jednoznačně identifikuje řádek). Mám nastavit index i na daný sloupec malé tabulky?

Upraveno uživatelem ¨safi
Odesláno
Děkuji moc všem za odpovědi. Mám tabulku, která má desítky tisíc řádků a v této tabulce sloupec, kde je číselníkem určena nějaká hodnota. Pak mám druhou tabulku, ve které mám desítky řádků - přiřazení slovních popisů jednotlivým hodnotám číselníku. Předpokládám, že bych měl u té velké tabulky na daný sloupec nastavit index (+ nastavit primární klíč na na sloupec, který jednoznačně identifikuje řádek). Mám nastavit index i na daný sloupec malé tabulky?

Můžeš sem postnout ze dva celé řádky z každé tabulky? Pro konkrétní představu?

Odesláno
Můžeš sem postnout ze dva celé řádky z každé tabulky? Pro konkrétní představu?

 

To právěže moc nejde...ta velká tabulka má asi 80 sloupců a obsahuje většinou hodně citlivá osobní data :-(

Odesláno (upraveno)
To právěže moc nejde...ta velká tabulka má asi 80 sloupců a obsahuje většinou hodně citlivá osobní data :-(

V čem to je? SQL server nebo Access nebo snad něco jiného? Zkus popsat, co s tím vlastně chceš udělat? Předpokládám, že spojit obě tabulky do nějaké relace, takže napsat SQL dotaz SELECT s požadovaným výsledkem.

Kukni třeba tady.

http://interval.cz/clanky/databaze-a-jazyk-sql/

 

Upraveno uživatelem VS
Odesláno
To právěže moc nejde...ta velká tabulka má asi 80 sloupců a obsahuje většinou hodně citlivá osobní data :-(

Pohoda B) Pokud jsem to pochopil správně, tak situace je jako jsem hodil na obrázku? (Teda například, samozřejmě v reálu tam máš položek mnohem víc.) Pak v první tabulce z číselníku uděláš primární klíč a identifikační relací jej spojíš s tabulkou druhou, kde ze stejného sloupce uděláš primární cizí klíč. Pak budou záznamy patřit k sobě a konstrukcí dotazu budeš schopen je navzájem skloubit. Jinak s tím indexováním Ti asi už neporadím, tak detailní zkušenost s databází nemám. Ono i záleží v čem to zpracováváš, myslím, že většina databází si to umí naindexovat sama a desítky tisíc záznamů by jí neměly činit problémy.

post-2220-1207136391.png

Odesláno

Thovte nemáš v tom trochu binec? Já bych skoro řekl, že ano, minimálně v té malůvce. Jak můžeš mít foreing key v 1:N relaci zároveň primárním klíčem té child tabulky? To by z toho přece jasně a automaticky dělalo 1:1 (případně 1:0) relaci.

 

Safi, Tvoje situace je v databázích poměrně typická. V té tabulce/číselníku o pár desítkách řádků nastavíš sloupec s jednoznačným identifikátorem (na který se odkazuje ta velká tabulka) jako PK. Pak vytvoříš relaci, kde zdrojem bude ten číselník a destination pak ta velká tabulka, ve které bude ten odkazovací sloupec tvořit Foreign key té relace. Pokud to někde nastavuješ, tak typ relace bude pravděpodobně 1:N (v případě, že odkaz ve velké tabulce je povinná hodnota).

 

Na velké tabulce budeš pochopitelně chtít mít i primární klíč (na nějakém jednoznačném sloupci), ale pro účely té relace je to irelevantní.

 

Jinak u indexování velice záleží na implementaci v konkrétním DBMS a jde-li o velké db, je to opravdu věda. Některé umí indexy s více sloupci, některé ne. U některých se určité typy indexů uplatní jen v určitých situacích. Většinou si můžeš nastavit i cachovací politiku (co se drží v paměti) atd. atd.

Odesláno (upraveno)
V čem to je? SQL server nebo Access nebo snad něco jiného? Zkus popsat, co s tím vlastně chceš udělat? Předpokládám, že spojit obě tabulky do nějaké relace, takže napsat SQL dotaz SELECT s požadovaným výsledkem.

Kukni třeba tady.

http://interval.cz/clanky/databaze-a-jazyk-sql/

 

 

je to MS Access...dotazy napsané mám..většinou je píšu přímo v SQL, ani nepoužívám ACCESS průvodce.

 

Jinak samotné SQL vypadá takto:

SELECT * xxxxx FROM (((consolidated_data_table LEFT JOIN ciselnik_typu_leasingu ON consolidated_data_table.C_TYPLEAS = ciselnik_typu_leasingu.cislo) LEFT JOIN ciselnik_OBM ON consolidated_data_table.A_ZOBCHODOVAL = ciselnik_OBM.Jmeno) LEFT JOIN ciselnik_PL ON consolidated_data_table.A_NAME1 = ciselnik_PL.podtyp1) LEFT JOIN [HeadMade-Adwise] ON consolidated_data_table.A_LVN = [HeadMade-Adwise].Cislo_smlouvy

WHERE xxxxxx

 

Tabulka ciselnik_pl ma na sloupci podtyp1 nastaven primární index

Tabulka consolidated_data_table má na sloupci C_TYPLEAS nastaven běžný MS ACESS index..

:thumbsup_anim: :thumbsup_anim: :thumbsup_anim: :thumbsup_anim:

Upraveno uživatelem ¨safi
Odesláno (upraveno)
Safi, rekni klientovi, ze si musi zaplatit konzultanta, a pak dej vedet, nejak se dohodnem :D

 

Dobře :-) pod 50% marži za služby třetích stran ovšem nejdeme :thumbsup_anim: ale nějaké inteligentní výplody ode mě nečekejte, právě jsme v práci otevřeli láhev koňaku :-) Nechcete jít někdo k nám pracovat? Alkoholické nápoje v pracovní době zdarma a pravidelně.

 

 

Upraveno uživatelem ¨safi
Odesláno
Dobře :-) pod 50% marži za služby třetích stran ovšem nejdeme :thumbsup_anim: ale nějaké inteligentní výplody ode mě nečekejte, právě jsme v práci otevřeli láhev koňaku :-) Nechcete jít někdo k nám pracovat? Alkoholické nápoje v pracovní době zdarma a pravidelně.

 

 

Jestli nahodou hledate nejakyho business analytika nebo konzultanta, tak klidne, u nas uz mi to leze na nervy :D

Ale mam par podminek: chci malej NTB, max. 13.3, chytrej telefon a rozumny penize :D

 

Jinak... 50 mi prijde jeste malo, poradne bych to napalil ;)

Btw, ted budu asi pro klienta delat takovej mensi reportovaci nastroj, resp. business analyzu a nasledne nejakej draft skriptu, zbytek dodela jinej team, pro me prace tak na 2-3 dny, pro vyvojovej tym tak na 1 den prace max. dvou lidi... a nas delivery manager nastrelil cenu za tohle pro klienta priblizne 30K USD. Kdybych z toho mel 5%, budu happy... :(

 

 

Odesláno
Thovte nemáš v tom trochu binec? Já bych skoro řekl, že ano, minimálně v té malůvce. Jak můžeš mít foreing key v 1:N relaci zároveň primárním klíčem té child tabulky? To by z toho přece jasně a automaticky dělalo 1:1 (případně 1:0) relaci.

Odborník nejsem, binec uznávám, ERD návrhy se nezabývám a pouze se v nich "orientuji" pro nezbytné konzultace při návrzích SW. Jsem víc ekonom než technik... Tzn. chtěl jsem Safimu pomoct, nespáchal jsem zločin, jen jsem to udělal halabala pro názornost bez dostatečných znalostí. Původně jsem odepisoval pouze na vysvětlení rozdílů... Ale když jsem viděl, že tu Safimu nikdo neodpovídá a že by se mu odpověď asi hodila, zkusil jsem to. Ale jinak jsem nechtěl nikomu fušovat do řemesla a do konstrukcí SQL příkazů bych se už nepouštěl vůbec. Ale pokud máš pocit, že v tom mám úplně binec, tak se jdu vrátit ke studiu ;) Tak jestli jsem Tě Safi moc mystifikoval, tak se omlouvám.

Odesláno
Odborník nejsem, binec uznávám, ERD návrhy se nezabývám a pouze se v nich "orientuji" pro nezbytné konzultace při návrzích SW. Jsem víc ekonom než technik... Tzn. chtěl jsem Safimu pomoct, nespáchal jsem zločin, jen jsem to udělal halabala pro názornost bez dostatečných znalostí. Původně jsem odepisoval pouze na vysvětlení rozdílů... Ale když jsem viděl, že tu Safimu nikdo neodpovídá a že by se mu odpověď asi hodila, zkusil jsem to. Ale jinak jsem nechtěl nikomu fušovat do řemesla a do konstrukcí SQL příkazů bych se už nepouštěl vůbec. Ale pokud máš pocit, že v tom mám úplně binec, tak se jdu vrátit ke studiu ;) Tak jestli jsem Tě Safi moc mystifikoval, tak se omlouvám.

 

V pohodě..oběma Vám děkuju moc za pomoc...v jednom případě mi indexace neskutečně pomohla. Abych odstranil duplicity ve zdrojových datech, tak jsem musel udělat pěkně komplikovaný dotaz, který mi bez indexace a primárních indexů nedoběhl ani za 10 minut. Po indexaci a nastavení primárních indexů to byly tři vteřiny :-)

Pokud chcete odpovídat, musíte se přihlásit nebo si vytvořit účet.

Pouze registrovaní uživatelé mohou odpovídat

Vytvořit účet

Vytvořte si nový účet. Je to snadné!

Vytvořit nový účet

Přihlásit se

Máte již účet? Zde se přihlaste.

Přihlásit se
×
×
  • Vytvořit...