ohmygod Posted April 2, 2007 Report Share Posted April 2, 2007 Kaut kur esmu sa*****s. Nu nekādīgi nevaru izdomāt, ka uztaisīt vaicājumu no vairākām tabulām un rezultātus izdot secīgi. Tb ir teiksim 5 tabulas ar 3 identiskām kolonnām. id, name, description Vajag info no viņām visām izdrukāt pēc kārtas uz leju. tb1.id1, tb1.name1, tb1.description1 tb1.id2, tb1.name2, tb1.description2 tb1.id3, tb1.name3, tb1.description3 tb1.id4, tb1.name4, tb1.description4 tb2.id1, tb2.name1, tb2.description1 tb2.id2, tb2.name2, tb2.description2 tb2.id3, tb2.name3, tb2.description3 tb2.id4, tb2.name4, tb2.description4 u.t.t. Gribētos to visu uztaisīt vienā vaicājumā - tā jau varētu taisīt katrai tabulai savu, bet pie LIMIT sanāktu čakars un pārāk daudz pieskārienu db. Link to comment Share on other sites More sharing options...
andrisp Posted April 2, 2007 Report Share Posted April 2, 2007 MYSQL UNION Link to comment Share on other sites More sharing options...
Grey_Wolf Posted April 2, 2007 Report Share Posted April 2, 2007 SELECT * FROM tabula1 UNION SELECT * FROM tabula2 UNION SELECT * FROM tabula3 Link to comment Share on other sites More sharing options...
ohmygod Posted April 2, 2007 Author Report Share Posted April 2, 2007 wops, cik vienkārši thnks (: Link to comment Share on other sites More sharing options...
Delfins Posted April 2, 2007 Report Share Posted April 2, 2007 Kāpēc ir jātur 3 tabulas ar identisku loģiku!? pieliec klāt lauku `ieraksta tips` Link to comment Share on other sites More sharing options...
Roze Posted April 2, 2007 Report Share Posted April 2, 2007 Kāpēc ir jātur 3 tabulas ar identisku loģiku!? Es nezinu vai tas ir konkrētais gadijums bet piemēram datu klusterēšana (kas MySQLam līdz šim (pirms 5.1) nav pieejama).. piem tabula_YYYYMMDD .. taču kaut kādas atskaites atkal javelk no visām tabulām. Varu teikt ka ir paliela starpība (MySQL gadijumā) lai vai kādi indeksi būtu uz tabulas vai tev dati jāvelk no viena 2Gb kluča nevis piemēram no 10 klucīšiem pa 200Mb katra. Link to comment Share on other sites More sharing options...
ohmygod Posted April 2, 2007 Author Report Share Posted April 2, 2007 (edited) Manā gadījumā tās ir kataloga kategorijas. Katra kategorija savā tabulā, katrai tabulai ir 7 kopīgi parametri, bet pārējās kolonnas ir maināmas, pievienojamas, dzēšamas. Par cik katrai kategorijai parametru skaits ir dažāds un nav ierobežots - katrai ir sava tabula Vienk bija nepieciešams garš saraksts ar pilnīgi visiem, visu, kategoriju ierakstiem. Uz ši pamata arī vienkāršāk taisīt kategoriju ierakstu salīdzināšanu, advanced search, pēc konkrētās kategorijas parametriem. Būtībā tie jau veidojas automātiski un nav neparko jākēro. + Rozes jau teiktais - nav jāmeklē dati no 50 kategorijām vienā tabulā - katrai ir savējā. Un vienlaicīgi vienmēr tiek lietota tikai viena - izņemot šo vienu skatījumu, kur man bija nepieciešami visi ieraksti. Edited April 2, 2007 by ohmygod Link to comment Share on other sites More sharing options...
Delfins Posted April 3, 2007 Report Share Posted April 3, 2007 kāpēc neizmantoji šo? categories: catid, name options: optionid, name, type, relation ... whatever categories_options: catid, optionid, value Link to comment Share on other sites More sharing options...
ohmygod Posted April 3, 2007 Author Report Share Posted April 3, 2007 Nu man arī tagad ir tabula ar kategorijām un tabula ar kategoriju parametriem. Man daudz pārskatāmāk likās strādās ar `category_catname` tabulām, kā ar vienu parametru tabulu. + ievades lauki var būt dažādi un attiecīgi arī veidojas kolonnas. Piemēram checkboxim pietiek ar tinyint(1), inputam char(150), texfieldam jau vajag vismaz text. Tad vienā kolonnā glabājot man būtu vainu jātaisa maximāli lielākais iespējamais vai arī jātaisa daudzas kolonnas ar dažādiem tipiem + katram jāatzīmē, kurā īsti kolonnā meklēt vajadzīgos datus. Tas būtu lieks čakars + nevajadzīgi daudz ierakstu savāktos un beigu beigās tabulas izmērs , iespējams, nedaudz piebremzētu pasākumu. Tavs variants no manējā atšķiras ar to, ka tavā būtu jau stingri nodefinēti mysql kveriji, bet man tie ģenerējas katrai kategorijai atkarībā no pieprasījuma. Tātad tur varētu rasties kādas kļūdas, problēmas (Jo tabula veidojas tā, kā lietotājs veido kategoriju), bet nu pagaidām esmu iztestējies krustu šķērsu un possible bugus izķēris Link to comment Share on other sites More sharing options...
Delfins Posted April 3, 2007 Report Share Posted April 3, 2007 (edited) Nu tur ir tikai 6 iespējamās vērtības/tipi date, time, smalltext, longtext, int, float === categories: catid, name, parent_catid options: optionid, name, type, typeName_1_defValue, [... typeName_1_defValue] categories_options: catid, optionid, typeName_1_value, [... typeName_N_value,] joins ari butu vienkars, meklesana pec DISTINCT vai kaa savadak Lidz ar to tev butu 3 tabulas, nevis tik cik grupas Ja vajag meklēt pēc kaut kā... tad es labāk nokešotu to visu un vērtības bāztu saformatētas vienā text laukā (max len jau var izrēķināt), bet datus glabāt tā ir ērtāk. Piemēram kešotais variants: catid, options_values 10 || "super", 10, 45.34, 2007-04-01, 15:00 Protams kešot var visu vai tikai teksta opcijas, kaadas nu tur ir prasibas. Starp citu, no datu bazes viedoklja, indeksi tiesi taa arii glabaa infu - lauks, pointers uz ierakstu, heš (~ kaut kas tam lidzigs).. lidz ar to beigas indeksi izskatisies ~ vienadi abiem variantiem un mekleshana notiks pec tiem.. mainas jau tikai CostPrice SQL selektam... Varianti optimizet ir daudz... Google tachu nespragst no terabaitu infas un miljonu online lietotiejiem :) Edited April 3, 2007 by Delfins Link to comment Share on other sites More sharing options...
Roze Posted April 3, 2007 Report Share Posted April 3, 2007 Google tachu nespragst no terabaitu infas un miljonu online lietotiejiem :) Nav jau tā ka googlei visi dati ir vienuviet.. kautkur bija zīmējums ar smukiem maziem BDB klusterīšiem ( http://sleepycat2.inetu.net/customers/pdfs...oogle_1005D.pdf ) Link to comment Share on other sites More sharing options...
Delfins Posted April 3, 2007 Report Share Posted April 3, 2007 Nē nu ka google ir klašteri sen zināms, bet priekš parastās kategoriju struktūras ir pārāk liels čakars. Un arī fakts, ja mysql (vai pāriešana uz citu normālu DB) būs partitioning, tad varēs to vienu tabulu noparticionēt.. nevis ies cauri 100 tabulām un mainīs/migrēs.. Link to comment Share on other sites More sharing options...
Roze Posted April 3, 2007 Report Share Posted April 3, 2007 ja mysql būs partitioningNu ir jau :) Un dažos keisos ir diezgan forši .. šis tas gan vēl ir bik salauzts.. Link to comment Share on other sites More sharing options...
Delfins Posted April 3, 2007 Report Share Posted April 3, 2007 Nu nezinu cik tas ātri strādā uz mysql un citos DB, bet tur nav nekas tik monstrīgs selektēt no lielas tabulas. Anyway, grozies kā gribi, SQL tik un tā vajadzēs ~ vienāds atmiņas lielums lai to visu izselektētu un atgrieztu. Link to comment Share on other sites More sharing options...
Roze Posted April 3, 2007 Report Share Posted April 3, 2007 Anyway, grozies kā gribi, SQL tik un tā vajadzēs ~ vienāds atmiņas lielums lai to visu izselektētu un atgrieztu. Nav gan gluži tā.. particionējot datus (fiziski) un arī klasterējot indeksus var panākt krietni labāku ātrdarbību, tapēc ka pēc tabulas un particijas definicijas DB serveris zin jau kurā apgabalā jāmeklē (t.i. visi indeksi nav nemaz jālasa). Arī OS līmenī ja 10Gb kluci tu nekādi failkešā (filecache) nedabūsi (protams ja serverim nebūs 10Gb+ rams) tad uzliekot tabulai 100 particijas 100Mb izmērā gan jau var mierīgi iestumt vidējas konfigurācijas servera ramā ;) Protams, ja pieprasītie dati trāpās pa visām partīcijām tad nekāds ātrdarbības ieguvums vairs nesanāk :) Link to comment Share on other sites More sharing options...
Recommended Posts