- Android alkalmazások - szoftver kibeszélő topik
- Profi EKG-s óra lett a Watch Fitből
- Honor 400 Pro - gép a képben
- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Samsung Galaxy A54 - türelemjáték
- Milyen okostelefont vegyek?
- Telekom mobilszolgáltatások
- Apple iPhone 16 Pro - rutinvizsga
- India felől közelít egy 7550 mAh-s Redmi
Új hozzászólás Aktív témák
-
biker
nagyúr
Kedves ügyfélnél összehányta magát a xampp alatti mysql-ben egy tábla
sem a szerkezet, sem az adatok nem nyerhetők ki, lockolva van, és sérültnek jelzi, restart megvolt, kézzel minden mókolás, hogy legalább a mysql szerver elinduljon, és a myadminba beléphessek megvolt, de a repair tables és a repair table táblaneve sem segít, nem tudja javítani, szerinte hiányzik az index
ha nem találnak egy backupot a xampp/mysql/data/táblaneve fileokból, akkor így jártak? google összes helpje eddig nem segített.
-
#2238
biker
nagyúr
hellsing71
#2237
biker
nagyúr
válasz
hellsing71
#2237
üzenetére
de ez ettől még két lekérdezés, csak egybeágyaztad
-
#2235
biker
nagyúr
hellsing71
#2234
biker
nagyúr
válasz
hellsing71
#2234
üzenetére
nem vonhatod össze, mert más alapján számol. szerintem. de valóban, századokat jelent csak
-
#2232
biker
nagyúr
hellsing71
#2229
biker
nagyúr
válasz
hellsing71
#2229
üzenetére
ennél egyszerűbb
Nálam több százezer soros táblák lapozóval
<script>
$(document).ready(function(){
$('#naploTabla').DataTable({
'processing': true,
'serverSide': true,
'serverMethod': 'post',
'ajax': {
'url':'ajax_naplo_file.php'
},
'columns': [
{ data: 'datum' },
{ data: 'esemeny' },
{ data: 'ertek' },
]
});
});
</script>a feldolgozó pedig
<?php
include("master.php");
// Create connection
try{
$conn = new PDO("mysql:host=$host;dbname=$adatbazis","$sql_felhasznalo","$sql_jelszo",
array(
PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES UTF8;',
PDO::ATTR_ERRMODE => PDO::ERRMODE_WARNING,
));
$conn->setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION);
}catch(PDOException $e){
die('Unable to connect with the database');
}
## Read value
$draw = $_POST['draw'];
$row = $_POST['start'];
$rowperpage = $_POST['length']; // Rows display per page
$columnIndex = $_POST['order'][0]['column']; // Column index
$columnName = $_POST['columns'][$columnIndex]['data']; // Column name
$columnSortOrder = $_POST['order'][0]['dir']; // asc or desc
$searchValue = $_POST['search']['value']; // Search value
$searchArray = array();
## Search
$searchQuery = " ";
if($searchValue != ''){
if (substr_count($searchValue, " ")==0)
{
$searchQuery = " AND (datum LIKE :datum or
esemeny LIKE :esemeny ) ";
$searchArray = array(
'datum'=>"%$searchValue%",
'esemeny'=>"%$searchValue%"
);
}
else
{
$searchValue_arr=explode(" ", $searchValue);
$i=1;
foreach($searchValue_arr AS $expl_value) {
$searchQuery.= " AND (datum LIKE :datum$i or
esemeny LIKE :esemeny$i ) ";
$searchArray = array(
"datum$i"=>"%$expl_value%",
"esemeny$i"=>"%$expl_value%"
);
}
}
}
## Total number of records without filtering
$stmt = $conn->prepare("SELECT COUNT(*) AS allcount FROM fitness_naplo{$_SESSION['helyszin']} ");
$stmt->execute();
$records = $stmt->fetch();
$totalRecords = $records['allcount'];
## Total number of records with filtering
$stmt = $conn->prepare("SELECT COUNT(*) AS allcount FROM fitness_naplo{$_SESSION['helyszin']} WHERE 1 ".$searchQuery);
$stmt->execute($searchArray);
$records = $stmt->fetch();
$totalRecordwithFilter = $records['allcount'];
## Fetch records
$stmt = $conn->prepare("SELECT * FROM fitness_naplo{$_SESSION['helyszin']} WHERE 1 ".$searchQuery." ORDER BY ".$columnName." ".$columnSortOrder." LIMIT :limit,:offset");
// Bind values
foreach($searchArray as $key=>$search){
$stmt->bindValue(':'.$key, $search,PDO::PARAM_STR);
}
$stmt->bindValue(':limit', (int)$row, PDO::PARAM_INT);
$stmt->bindValue(':offset', (int)$rowperpage, PDO::PARAM_INT);
$stmt->execute();
$empRecords = $stmt->fetchAll();
//echo "ok";
$data = array();
foreach($empRecords as $row){
// echo "ok";
$data[] = array(
"datum"=>$row['datum'],
"esemeny"=>translated($row['esemeny'], $_GET['sel_lang']),
"ertek"=>$row['ertek']
);
}
## Response
$response = array(
"draw" => intval($draw),
"iTotalRecords" => $totalRecords,
"iTotalDisplayRecords" => $totalRecordwithFilter,
"aaData" => $data
);
echo json_encode($response);
?>nyilván testre kell szabnod, de az elv ennyi, ajaxxal hívogatja, és küldi melyik 10 vagy 25 vagy 100 sort kérje le
-
biker
nagyúr
Sziasztok!
Hogy lehet elérni mysql-ben, hogy ha az eeredmény egy sort se érint, akkor ne NULL legyen hanem 0 vagy 1?
Coalesc nem oldja meg, az csak azt oldja meg, hogy ha van benne null sor az átlagban, akkor beleszámolja az elemekbe vagy semMaga a lekérdezés naplóból a belépés-kilépés közti idők átlaga
$atl_bent=$db->query("SELECT AVG(SUBSTRING_INDEX(SUBSTRING_INDEX(esemeny,' ',-2),' ',1)) FROM fitness_naplo{$_SESSION['helyszin']} WHERE esemeny LIKE '%[ {$query_tomb['id']} ]%' AND esemeny LIKE '%bent töltött idő:%'")->fetchAll();A helyzet az, hogy kb 80-100 tárhelyen fut hibátlanul a kód, de egy új tárhelyen valami rejtélyes okból fatal errorral elszáll ha ez a sor benne van, mert a fetchall nem futtatható boolean elemen, azért boolean mert null az eredmény.
ha van idő, akkor hibátlan.Az egy dolog, hogy senki nem tudja, melyik php vagy mysql beállítás okozza a fatal errort, ha máshol nem okoz hobát, de valahogy át lehet-e írni hogy a NULL helyett 0 legyen ha nincs egy elem sem?
-
biker
nagyúr
Az END után nincs pontosvessző, szerintem, utána // és DELIMITER ;
DELIMITER //
CREATE PROCEDURE allomany_masolas(allomany VARCHAR(255))
BEGIN
DECLARE allomany_mentes_ VARCHAR(255);
DECLARE sql_C TEXT;
-- Az új táblanév létrehozása az aktuális dátum alapján
SET allomany_mentes_ = CONCAT(allomany, '_', DATE_FORMAT(NOW(), '%Y_%m_%d'));
-- SQL parancs összeállítása
SET sql_C = CONCAT('CREATE TABLE ', allomany_mentes_, ' AS SELECT * FROM ', allomany);
-- SQL parancs végrehajtása
PREPARE stmt FROM sql_C;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;
END ;
//
DELIMITER ; -
biker
nagyúr
Mit szólnátok, ha olyan programkód kerülne elétek, amihez így néz ki az adatbázis?
CREATE TABLE `Kategóriák` (
`id` int(10) UNSIGNED NOT NULL,
`azonosító` tinytext CHARACTER SET ascii NOT NULL,
`szülö` int(10) UNSIGNED NOT NULL,
`kép` varchar(100) COLLATE utf8_hungarian_ci NOT NULL,
`háttérkép` int(11) NOT NULL,
`galéria` int(11) NOT NULL,
`sorrend` int(10) UNSIGNED NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_hungarian_ci;
CREATE TABLE `KategóriákNyelv` (
`id` int(10) UNSIGNED NOT NULL,
`nyelv` int(10) UNSIGNED NOT NULL,
`név` tinytext COLLATE utf8_hungarian_ci NOT NULL,
`leírás` text COLLATE utf8_hungarian_ci NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_hungarian_ci;de a legjobb ahol keveri az ékezetes és ekezettelenul írt mezőket, és egy kis angolt is beletesz. nem, nem a file marad file, az fájl lett
CREATE TABLE `Termékek` (
`id` int(10) UNSIGNED NOT NULL,
`kód` varchar(30) COLLATE utf8_hungarian_ci NOT NULL,
`ár` int(10) UNSIGNED NOT NULL,
`beszerzesiar` int(11) NOT NULL,
`nyereseg` int(11) NOT NULL,
`marka` int(11) NOT NULL,
`markalink` varchar(300) COLLATE utf8_hungarian_ci NOT NULL,
`kiszereles` varchar(200) COLLATE utf8_hungarian_ci NOT NULL,
`akciósár` int(10) UNSIGNED DEFAULT NULL,
`nettoar` int(11) NOT NULL,
`beszerzesiar_huf` varchar(300) COLLATE utf8_hungarian_ci NOT NULL,
`beszerzesiar_eur` varchar(300) COLLATE utf8_hungarian_ci NOT NULL,
`cimkek` varchar(1000) COLLATE utf8_hungarian_ci NOT NULL,
`akciókód` varchar(200) COLLATE utf8_hungarian_ci NOT NULL,
`cikkszám` varchar(100) COLLATE utf8_hungarian_ci NOT NULL,
`áfa` int(10) UNSIGNED NOT NULL,
`darab` int(10) NOT NULL,
`készletinfó` varchar(300) COLLATE utf8_hungarian_ci NOT NULL,
`súly` int(11) NOT NULL,
`elektronikus` enum('NEM','IGEN') COLLATE utf8_hungarian_ci NOT NULL,
`fájl` varchar(300) COLLATE utf8_hungarian_ci NOT NULL,
`állapot` enum('AKTÍV','TÖRÖLVE','ELÖKÉSZÜLETBEN') COLLATE utf8_hungarian_ci NOT NULL,
`azonosító` tinytext CHARACTER SET ascii NOT NULL,
`idöpont` datetime NOT NULL,
`kiemelt` tinyint(4) NOT NULL,
`argep` tinyint(1) NOT NULL,
`arukereso` tinyint(1) NOT NULL,
`olcsobbat` tinyint(4) NOT NULL,
`hasznalati` varchar(300) COLLATE utf8_hungarian_ci NOT NULL,
`adatlap` varchar(300) COLLATE utf8_hungarian_ci NOT NULL,
`video` varchar(300) COLLATE utf8_hungarian_ci NOT NULL,
`videohasznalati` varchar(300) COLLATE utf8_hungarian_ci NOT NULL,
`kiemeltsorrend` int(11) NOT NULL,
`sorrendegy` int(11) NOT NULL,
`sorrendketto` int(11) NOT NULL,
`sorrendharom` int(11) NOT NULL,
`sorrendnegy` int(11) NOT NULL,
`title` varchar(300) COLLATE utf8_hungarian_ci NOT NULL,
`seogeneral` tinyint(4) NOT NULL DEFAULT '1',
`description` varchar(300) COLLATE utf8_hungarian_ci NOT NULL,
`sharetitle` varchar(100) COLLATE utf8_hungarian_ci NOT NULL,
`sharedescription` varchar(200) COLLATE utf8_hungarian_ci NOT NULL,
`shareimage` int(11) NOT NULL,
`osszehasonlito` tinyint(4) NOT NULL,
`osszehasonlitokategoria` int(11) NOT NULL,
`variacio` tinyint(4) NOT NULL,
`szulo` int(11) NOT NULL,
`variaciosorrend` int(11) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_hungarian_ci; -
biker
nagyúr
válasz
nevemfel
#2204
üzenetére
Ezen elgondolkoztam, és sikerült rekonstruálni a sztut
Az installer script amit írtam eddig id ugyanaz volt, meg a query. Igenám, de lusta módon csak olyanok voltak benne hogy pl mezőneve text not null (default nélkül)
Érdekes módon ha ebbe a táblába beszúrtam egy sort ahol egy ilyen mezőbe nem adtam meg értéket, akkor mivel null nem lehet üres lett. Mintha a szerveren lenne egy globális default ‘’
A mai telepítéskor feltűnt hogy beszúráskor hibával nem ír be ha nem adok meg értéket, mivel not null mezőbe kért adatot. Én meg hülye módon default null és nem default ‘’ beállítással orvosoltam a beszúrást
És valoban ezért lett ezen a szerveren az érték nélküli mező és nem üres -
biker
nagyúr
válasz
nevemfel
#2202
üzenetére
Ezt a kódban kikeresni, hány lekérdezés érintett, kicsit gyilkos lenne
Egyelőre úgy tűnik hogy a tábláknál a default null helyett default ‘’ megoldja a problémátDe jó lenne tudni, az a tárhely mysql beállítás a hibás ahol ez hibás, vagy ahol ez jó
Mert eddig mondjuk 150 helyen ez nem volt hiba, a 150 tár a roossz?
-
-
biker
nagyúr
Üdv, milyen szerver beállítás eredményezhet ilyen hibát? Eddig sosem láttam hasonlót
Példa: SELECT * FROM berletek WHERE aktiv!='n' ORDER BY berlet_neve ASC
és az aktiv mező NULL (üres) ha aktiv, ’n’ ha inaktív, akkor ha NULL a mező, akkor eldobja az sql-t. Ilyennel még nem találkoztam.
Explain mód: "Impossible WHERE noticed after reading const tables”
Vagyis ha a mező null, akkor lehetetlen benne where feltétellel keresni?
Próbálom a tárhelyest elérni, állítson valamit, de mit? -
biker
nagyúr
Na, kipróbáltam, remélem mindent jól következtettem ki
Leginkább az ÉS lassítja.
Ha ugyanazt keresem 1x, vagy 2x, vagy 2 mezőben egyszer, akkor OR esetén mindegy.
AND esetén ha ugyanazt keresem, nem gond, de ha két külön feltételt AND-el, akkor mindkét esetben lassulPersze, ez a saját gépemen, ahol minden erőforrás itt van a mysql-nek, vhoston lehet hogy jobban kijön a különbség, hogy nem 0,0030 vs 0,0020 hanem egy tizedessel beljebb jövünk, de nem lényeg.
mysql teszt, 242,7mb tábla
v1: 744.000 sor szöveg keresés egy mezőben, egy feltétellel
SELECT * FROM `fitness_naplo_dup` WHERE `esemeny` LIKE '%rendszer%'
Sorok megjelenítése 0-24 (összesen 68691, A lekérdezés 0.0032 másodpercig tartott.)v2: 744.000 sor szöveg keresés egy mezőben, két feltétellel
SELECT * FROM `fitness_naplo_dup` WHERE `esemeny` LIKE '%rendszer%' OR `esemeny` LIKE '%törölt%'
Sorok megjelenítése 0-24 (összesen 100520, A lekérdezés 0.0030 másodpercig tartott.)SELECT * FROM `fitness_naplo_dup` WHERE `esemeny` LIKE '%rendszer%' AND `esemeny` LIKE '%törölt%'
Sorok megjelenítése 0- 0 (összesen 1, A lekérdezés 2.1407 másodpercig tartott.)v3: 744.000 sor szöveg keresés két mezőben, egy feltétellel
SELECT * FROM `fitness_naplo` WHERE `esemeny` LIKE '%rendszer%' AND `esemeny2` LIKE '%rendszer%'
Sorok megjelenítése 0-24 (összesen 68691, A lekérdezés 0.0018 másodpercig tartott.)SELECT * FROM `fitness_naplo` WHERE `esemeny` LIKE '%rendszer%' OR `esemeny2` LIKE '%rendszer%'
Sorok megjelenítése 0-24 (összesen 68691, A lekérdezés 0.0026 másodpercig tartott.)v4: 744.000 sor szöveg keresés két mezőben, két feltétellel
SELECT * FROM `fitness_naplo` WHERE `esemeny` LIKE '%rendszer%' AND `esemeny2` LIKE '%törölt%'
Sorok megjelenítése 0- 0 (összesen 1, A lekérdezés 1.3561 másodpercig tartott.)SELECT * FROM `fitness_naplo` WHERE `esemeny` LIKE '%rendszer%' OR `esemeny2` LIKE '%törölt%'
Sorok megjelenítése 0-24 (összesen 100520, A lekérdezés 0.0026 másodpercig tartott.) -
biker
nagyúr
Lenne egy elméleti kérdésem. Keresés-sebesség kapcsán.
Ha van egy tábla, mondjuk
id, text, date
és ebben keresek szabad szavasan a text mezőben, akkor az ugye egy időegységHa ezt így készítem többnyelvűre, hogy
id, text_hu, text_en, text_de, date
és minden nyelvben keresek előfordulást, az 3 időegység, vagy esetleg kettő, de mindenképpen több mint egy!De ha a többnyelvű szöveget egy text mezőben tárolom pl {:hu}szöveg{:en}text{:de}sprache{:} módon, akkor hiába lesz kbyte-ra ugyanannyi a tábla, mivel minden szöveg egy oszlopban van, a keresés ideje szintén egy időegység nem? és egy keresési parancsal tudok minden nyelvre előfordulást keresni
Persze százezer sorokról beszélünk, több nyelven.
-
biker
nagyúr
Van egy óriási különbség kettőnk közt:
-te nem értesz hozzá, kicsit sem, de szerinted 4 adat 1 napos munkával
-én meg már írtam is ilyen szoftvert olyan célközönségnek akinek a gyári nem volt jó, és tudom hogy nem 4 adat 1 nap alattDe legalább azt ne felejtsd ki, hogy ha benne is van a szerinted 4adat az sqlben, az még pont semmire nem jó
Sok sikert, keresgélj tovább. De elsősorban próbáld megtalálni a megfelelő topikot hozzá
-
biker
nagyúr
ok, még egyszer utoljára megpróbálom, hátha megérted...
- MINDEN valamire való collaborációs rendszer alapeleme, hogy online legyen, ez a CRM-re is igaz. Tehát kell egy webserver. Ezt már korábban is leírtam, hogy tedd fel webserverre, vagy xampp/wampp-ra, vagy egy NAS-ra. Nem azt írtam kedves értetlenke, hogy csak nason fut. Érted? amúgy ne a felvágottas pultban keresd a nas-t, ha mész érte
- a DEV verzió annyit tesz, nem kiadásra szánt tökéletesnek gondolt verzió, hanem amiben lehet fejlesztés alatt álló funkció is, nincs hozzá terméktámogatás, csak fórumon. ha nem tetszik, van millió másik crm, persze pénzért mind.
- nem gondolom, hogy az én hibám, hogy nem értesz angolul.kicsit szállj magadba
-
biker
nagyúr
Ez a nem létező sugarCRM Community Edition letöltő oldala
Download Sugar Community Edition for Free
Ez meg a dokumentáció
Normálisabb NAS-okon előre telepítve elérhető INGYEN, felrakod egy webserverre, nasra, vagy saját gépen xampp-raNem, nem én szartam a spanyol viaszt, de te vagy az, aki write only módban fórumozik, csak ír, kérdez, de nem hajlandó olvasni, tanulni, keresni
-
biker
nagyúr
Nem felejtik el, egy CRM rendszer annyit ér, mint vérpistikének az alaplap hex error code checker, vagy a szomszédjózsinak az OBD olvasó az autóhoz.
sz@rt se ér.Amikor bekonfigurálod, felveszed a usereket, jogosultságokat kiosztod, folyamatokat tervezel, stb stb stb
akkor belemegy olyan 100 munkaóra, ez 6-8000Ft/órával lehet számolni.Ha neked az fárasztó, hogy regisztrálj egy letöltésért, és elolvass 100 oldal doksit, akkor ez nem a te pályád, fizess meg valakit.
Nem gondolod, hogy most a kedvedért valaki nyit egy ingyenes crm konfigurálás tanfolyamot? Van ilyen a neten, googlizz.Konkrét kérdésben fogunk tudni segíteni, mint mondjuk ha programozás akkor "hogyan alakítsak át egy szöveget tömbbé" de olyanban nem, hogy "hogyan írjak egy facebookhoz hasonló oldalt"
-
-
biker
nagyúr
válasz
martonx
#1804
üzenetére
kompatibilitás miatt nem ok, át kéne írni hozzá a php nagy részét, ott mindenhol timestamp-el számolok, és a többi 50 rendszer használó is ebben mozog, és őket nem zavarja a pontos óra-perc-mp számolás.
így csak miatta lenne egy olyan alverzió, ahol minden timestamp > < = át kellene írni date_diff-ekkel operálásra, meg strotime-okra, ami inkább macerás, mint egyszer lefuttatni neki ezt.
Generál probléma, egy bérlet 30 napig érvényes, pl.
ha 1-én reggel 8-kor megveszi, és az 31-én reggel 8-ig érvényes, akkor van 30 napja.
ha 31-én 23 óráig érvényes, akkor 31 napja lett, nem? Na ezt van aki képtelen megérteni, mert nem tudja, hogy 30 nap az nem 31 nap. És azzal jön, hogy 31-én még évényesnek kellene lennie a bérletnek böööööö
-
#1803
biker
nagyúr
Apollo17hu
#1802
biker
nagyúr
válasz
Apollo17hu
#1802
üzenetére
Köszi a tippet
Nem szép, de legalább ocsmány, és működik
timestamp>>dátum:óra:perc>>levágás>>időlevonás>>unixtimeUPDATE fitness_users_berletek SET berlet_erv =
(UNIX_TIMESTAMP(DATE_ADD(DATE(DATE_FORMAT(FROM_UNIXTIME(`berlet_erv`), '%Y-%m-%d %H:%i:%s')), INTERVAL - 61 MINUTE))) -
biker
nagyúr
Fincsi kérdésem lenne
Tömeges dátummódosítás, elakadtam
Lenne 1200 dátum, időbélyegben (unixtime)
Ok, hogy lekérdezhetem "emberi formában" így:
SELECT DATE_FORMAT(FROM_UNIXTIME(`berlet_erv`), '%Y-%m-%d %H:%i:%s') AS 'date_formatted' FROM `fitness_users_berletek` WHERE 1
Pulsz mikor php-ben megjeleníte, akkor szép is, hiszen erre van a dateDE!
Kedves ügyfél kérése, hogy a különböző óra/perc-ben lejáró bérletek mindegyike adott nap 23:59:59-kor járjanak le
Tehát módosítsunk 1200 dátumot innen:
2016-04-19 12:32:41
2016-05-10 17:39:21
stberre:
2016-04-19 23:59:59
2016-05-10 23:59:59Mit tehetek mezei sql eszközökkel? Nem szeretnék komplett feldolgozó scriptet írni rá, ha nem gond, hadd tanuljak már egy igen összetett sql paranccsal
-
biker
nagyúr
egy más által félbehagyott szart kell felélesszek, és valamit nem értek
1: Előbb létrehoz két view táblát:
CREATE TABLE IF NOT EXISTS `country_views` (
`id` smallint(6)
,`countryName` varchar(50)
,`countryCode` varchar(2)
,`ISO2` varchar(2)
,`ISO3` varchar(3)
,`ISON` varchar(4)
,`Internet` varchar(2)
,`Capital` varchar(25)
,`MapReference` varchar(50)
,`NationalitySingular` varchar(35)
,`NationalityPlural` varchar(35)
,`Currency` varchar(30)
,`CurrencyCode` varchar(3)
,`Population` bigint(20)
,`Title` varchar(50)
,`Comment` varchar(255)
,`id_code` varchar(9)
);
CREATE TABLE IF NOT EXISTS `view_p_files` (
`user_id` int(11)
,`id` int(11)
,`order_id` int(11)
,`file_id` int(11)
,`quantity` smallint(6)
,`amount` double(7,2)
,`download_count` smallint(6)
,`created` datetime
,`modified` datetime
);Majd utána ezt (emiatt nem is fut le az import, nincs jogom ilyen futtatásra)
--
-- Structure for view `country_views`
--
DROP TABLE IF EXISTS `country_views`;
CREATE ALGORITHM=UNDEFINED DEFINER=`sausuman`@`localhost` SQL SECURITY DEFINER VIEW `country_views` AS (select `countries`.`id` AS `id`,`countries`.`countryName` AS `countryName`,`countries`.`countryCode` AS `countryCode`,`countries`.`ISO2` AS `ISO2`,`countries`.`ISO3` AS `ISO3`,`countries`.`ISON` AS `ISON`,`countries`.`Internet` AS `Internet`,`countries`.`Capital` AS `Capital`,`countries`.`MapReference` AS `MapReference`,`countries`.`NationalitySingular` AS `NationalitySingular`,`countries`.`NationalityPlural` AS `NationalityPlural`,`countries`.`Currency` AS `Currency`,`countries`.`CurrencyCode` AS `CurrencyCode`,`countries`.`Population` AS `Population`,`countries`.`Title` AS `Title`,`countries`.`Comment` AS `Comment`,concat(`countries`.`id`,'_',`countries`.`countryCode`) AS `id_code` from `countries`);
-- --------------------------------------------------------
--
-- Structure for view `view_p_files`
--
DROP TABLE IF EXISTS `view_p_files`;
CREATE ALGORITHM=UNDEFINED DEFINER=`sausuman`@`localhost` SQL SECURITY DEFINER VIEW `view_p_files` AS select `orders`.`user_id` AS `user_id`,`order_details`.`id` AS `id`,`order_details`.`order_id` AS `order_id`,`order_details`.`file_id` AS `file_id`,`order_details`.`quantity` AS `quantity`,`order_details`.`amount` AS `amount`,`order_details`.`download_count` AS `download_count`,`order_details`.`created` AS `created`,`order_details`.`modified` AS `modified` from (`order_details` join `orders`) where (`orders`.`id` = `order_details`.`order_id`);Ez mire jó?
2: mire jó, ha van 32 táblám, és abból 27db innodb, 5db myisam? Így sikerült, vagy lehet valami nagyon jó indoka rá?
-
-
biker
nagyúr
é 2 hete ezen dolgoztam pont, csak itt a másik oldal tagait kellett phpbb-be tolni, és arra jutottam, nem lehet kikerülni a phpbb saját reg-jét, mert túl sok mindent kavar
- adat nem írható be az ő users táblájába, mert saját jelszó kódolási eljárását ki kell akkor venni az ucp-ből, ugyanis a jelszó mellé letárol egy saltot, majd a kódolt jelszót. ha nem ezt használod, akkor belépéskor nem fog passzolni a jelszó
- emailt szintén generál egy kódolt verziót is, hogy kívülről ha valaki átírja az emailt, nem passzol a tárolt hash-el, buktad.
- user form megnyitáskor generál egy időbélyeget és annak lejárata van, ha nem passzol, invalid a form.
- ha nem az ucp.php oldalról érkezel invalid a form. ha nem fogadod el a feltételeket MIELŐTT regisztrálsz, invalid a formÉs aztán azt mondtam, dögölj meg ahol vagy, a "másik" oldal adatmódosítás részbe, ahol be van lépve a tag, kiraktam egy gombot, mögötte egy formmal, hogy regisztrálok a fórumba, azzal meghívva az ucp-t a phpbb-ben, ahol a név/email mezők readonlyvá vannak téve, így csak azzal lehet regelni, aki belépett a másik oldalon, és azonos lesz a neve a fórumban is. Így is el kell fogadni a feltételeket is előtte, de ez már működő megoldás, átadva az adatokat
-
biker
nagyúr
válasz
martonx
#1540
üzenetére
a célirányos kereséssel nincs gond, és nagyon a szerkezettel sem, mivel félreérted, nem a lényegi infó van több tábla több oszlopában, hanem a kapcsolódó infók.
Adott az adatlap (sajnos ezen van a 130 oszlop amiből kb 100-ra keresni is kell) de van még 3 tábla, értékelésekkel, és kapcsolódó írásokkal amivel jó lenne kapcsolódva keresni.
Ezekből kb 15 szöveges mező (amiben fulltext search kell) és a maradék az olyan opciós kapcsolós oszlop lista, mint egy biztosítós vagy autókereskedős tábla (igen/nem, alap/extra/nincs és hasonlók)
és ugye az összes keresésnél olyat szeretne az ügyfél, hogy ha rákeres az "alma" szóra, akkor a szövegekben lévő alma szóra is keressen, meg a 100 hülye opciós listából is arra, ahol az alma ki van választvaránézek erre a lucene-re, köszi
-
biker
nagyúr
Egy is "mindenhol keresés" témában érdeklődöm
Adott egy ügyfél, van 10 táblában összesen kb 200 oszlop, benne tartalom.
Szeretne egy "mindenben keres" verziót.Ezt hogy lehet szépen és erőforrásigényesen megoldani?
Index és match-against oszlopszám limites, és egy 200 soros like-os lekérdezés sem épp szép
Azon gondolkozom, egy view-t létrehozni, amiben csak a tábla neve, oszlop neve, sor_ID, és szöveg oszlopok vannak, és ezen futtatok keresést, akkor a találat megadja, melyik tábla mely sorát kell visszaadni, és miben találta (oszlop)
ez járható út, vagy van jobb?
-
#1515
biker
nagyúr
trisztan94
#1514
biker
nagyúr
válasz
trisztan94
#1514
üzenetére
Nem exportálni akarom, hanem lekérni. Akár többször is egymás után.
Ezt fejtsd ki, szerinted mi az exportálás és a teljes adatbázis lekérése közti különbség???
Mert szerintem egy tábla összes adata, vagy egy adatbázis összes táblájának összes adata lekérése exportálás -
#1513
biker
nagyúr
trisztan94
#1511
biker
nagyúr
válasz
trisztan94
#1511
üzenetére
és a kettő közt mia különbség?
-
#1510
biker
nagyúr
trisztan94
#1505
biker
nagyúr
válasz
trisztan94
#1505
üzenetére
Google: mysql export database command line ????
-
#1450
biker
nagyúr
Sk8erPeter
#1447
biker
nagyúr
válasz
Sk8erPeter
#1447
üzenetére
haha, szólj ha felnőttél...
-
#1440
biker
nagyúr
Sk8erPeter
#1439
biker
nagyúr
válasz
Sk8erPeter
#1439
üzenetére
"az akciós kérdésben nem értünk egyet, a többiben igen"
Eddig úgy tűnt, azt írtad le, hogy a termékek alapvető adataival egy táblában kezeled, mikor kezdődött, és zárult le egy bizonyos időszakban bevezetett akció, meg mi az akciós és korábbi ár, és hasonlók, és ezeket kell mindig felülírni módosításkor, de ha utólag ki akarnál egy kimutatást készíteni arról, hogy melyik időszakban milyen áron, milyen akció keretében, mekkora kereslet volt az adott termékre, akkor gondban lennél, mivel nincs history-szerűen nyilvántartva, korábban milyen árakon futott a termék (és mikor), csak felül van csapva a korábbi érték, aztán kész. De lehet, hogy ebben félreértés volt, és nem így kell elképzelni, abból indultunk ki, amilyen információkat leírtál.Van egy ömlesztett napló, amiben minden módosítás benne van, ebből kikereshető a kérdésre a válasz, de mondtam azt is, nem a legrugalmasabb, de ott van.
nyilván, ha külön helyen van kezelve, ez jobban követhető, van akinek még ez a naplózás is felesleges. -
#1434
biker
nagyúr
Sk8erPeter
#1430
biker
nagyúr
válasz
Sk8erPeter
#1430
üzenetére
nem, csak fáradt vagyok.
írtad, nem bírom a kritikát. de bírom, de kritizálni azt lehet, amit ismerünk, nem hallottunk róla.
tegnap el is kezdtem nézni Alföldi István a királyát, de rá kellett jöjjek, tényleg szar, előre nem írtam le a cuccot, hátha csak a kritikusok azok, de nem, tényleg az volt.a jelen állapotában lévő webshopom egy 2006-os, akkor kb 3 tábla összesen 30 oszlopából fejlődött egy 13-14 táblából, azokban összesen vagy 120 oszlopos szörnyeteggé, 7. verzió, toldozva foldozva, és nem volt kedvem modernizálni, mert nincs akkora kereslet fizetős webshopra, hogy dolgozzak és töltsem az időt, mert csak fizetős időm van, szabad időm 4 éve nincs, hogy hobbira magamnak fejlesszek.
A rendszer "működőképes", és nem "optimális" és nem "szent". Nem is állítottam soha, hogy csak így lehet, és ez a jó út, azt mondtam, működik, és nem értem, miért CSAK másképp lehet, ahogy ti mondjátok
(jut eszembe, várom a hirdetésem linkelését a kollégától még)Majd ha ez emberek nem a woocommerce féle ingyen sz@rokat keresik, lehet ki lesz fejlesztve a modern verziója, addig nem.
az akciós kérdésben nem értünk egyet, a többiben igen
és nem hinném, hogy ettől, hogy itt szétszedtetek darabokra, bármi hibát elkövettem volna az utóbbi pár év fejlesztéseiben (nem 2006-ban meg előtte, mikor még tapasztalat nem volt) mivel minden azóta írt egyedi rendszerem (szerintem) okosan szét van szeparálva, legyen az a fitness szoftver, aminél a tagokat, bérleteiket, vásárlásaikat kezeli a rendszer, sok sok táblában sok sok XY_ID kapcsoatokkal, joinokkal, vagy legyen az a szerviztámogató program, ahol tagok-kapcsolattartók-címek-klímák-események-munkalapok rendszerezése és kezelése folyik, ugyanígy, és azon kell vitatkozzak a kedves megrendelővel, hogy nem, qrvára nem kellene egy munkalap szám alá 4 klíma javítást felvinni, mert nem releváns infó, egyik gépen ezt csináltam, másikon azt, ha 1 év múlva csak X klíma érdekel, ne hozza már le munkalap kapcsolat miatt Y Z klímákat is, de nem akarja megérteni, mert szerinte 15 lapot nem lehet borítékbe tenni, mert nem látott még L6-ná nagyobb borítékot.
az ok azt jelentette, olvastam, köszönöm, nincs mondanivalóm, mert nem érek rá ontani a szót, és nem mosdatni akarom magam.
-
#1429
biker
nagyúr
Sk8erPeter
#1428
biker
nagyúr
válasz
Sk8erPeter
#1428
üzenetére
ok
-
#1426
biker
nagyúr
fordfairlane
#1424
biker
nagyúr
válasz
fordfairlane
#1424
üzenetére
átlag usernek ez amit írsz bonyolultabb, mert neki az kell, ez a termék holnap ennyibe kerül, ma meg annyiba, nem akar külön akciót definiálni, majd termékkört dfiniálni, abba terméket bevonni, stb
Ugyanez a cimkére, igen, ez a helyes út
termékid;termék
1;alma
2;körtecimkeID;cimke
1;piros
2;sárga
3;lédús
4;édescimke_termék kapcsolatok
termékID;cimkeID
1;1
1;4
2;2
2;3
2;4pl, de ekkor a user ha később kedve szottyan átírni a pirost vörösre, mert a retek nem piros hanem vörös, akkor minden alma is vörös lesz, és idegeskedik majd, sajnos, van ilyen réteg, úgy a userek 70-80%-a
nekik jobb ha símán ömleszted és nem külön cimke kezelés, mert cak zavarja a sok cimke -
#1425
biker
nagyúr
fordfairlane
#1423
biker
nagyúr
válasz
fordfairlane
#1423
üzenetére
így lehet értelme, de ez nem webshop kategória már, hanem VIR, egy mezei webshopnál ez már ágyúval verébre.
Most hirtelen néztem 3 közkeletű webshop motort, mindenhol a terméklapon állítom be az akciós időszakot és árat, nem találok külön ilyen bonyolult megoldáson alapuló akció szerkesztéses dolgot. vagy csak elkerülte a figyelmem. -
#1422
biker
nagyúr
fordfairlane
#1421
biker
nagyúr
válasz
fordfairlane
#1421
üzenetére
az alapoktol zavaros amit irsz
Egyaltalan Te erted?1: letrehozok egy termekre vonatkozo akciot mikor nincs ilyen termekem? Hogy? Miert? Es ha ez kulon tablaban van mitol jobb, ha nincs ilyen termek?
Ugyanez arra, hogy ha torlom a termeket akkor megmarad az akcioEz szamomra ertelmezhetetlen
Mert hiaba irom ki holnaptol -10% a sörre ha nincs sör
Ezt ertelmes, eletszeru peldan mutasd be kerlek
Mert nalunk ugy megy, hogy kitalaljuk melyik termekunk mettol meddig akcios, nem pedig kitalaljuk holnap valami akcios lesz, de nem tudom mi
-
#1419
biker
nagyúr
Sk8erPeter
#1416
biker
nagyúr
válasz
Sk8erPeter
#1416
üzenetére
"akciók pedig símán összeköthetők ak ezdő és vég időponton keresztül, nem is értem a felvetést, miért ne lehetne?". Ez alapján komolynak tűnik, akkor viszont alapvető tervezési elveket sértesz meg, pedig ahogy már írták, ezek szétbontása tényleg az első pár adatbázis-kezelési és -tervezési lecke között van, és akkor ezek szerint az nagyon kimaradt.
Ne viccelj, miért ne lehetne kigyűjteni egy selecttel az összes terméket ami mondjuk a köv 10 napban akciós ?
Ugyanazzal a lekérdezéssel lehet, mint amivel külön tábla esetén tennéd, és joinolnád az id-khez a termékeket a termékek táblából, nem?Itt az az alap tézis részetekről, csak rossz lehet mert sok oszlopa van
Pont ugyanúgy és ugyanaz elvégezhető így isAz echo "hello world"; is leírható így is
<?php
class myClass
{
function sayHello()
{
echo "Hello there!";
}
}
?><?php
require_once('myClass.php');
$myClass = new myClass();
$myClass->sayHello();
?>
-
#1418
biker
nagyúr
Peter Kiss
#1417
biker
nagyúr
válasz
Peter Kiss
#1417
üzenetére
Kérlek mutasd meg a hirdetésem, mert az aláírásban lévő szöveg, ami nem is link, körítés nélkül nehezen értelmezhető szolgáltatás hirdetésként, fikaverseny győztese cím ezennel a tied
-
biker
nagyúr
mindenkinek egyszerre válaszolok, és le is zárom, mert látom, egyetlen célotok, fikázni, és most ehhez fáradt vagyok. sok lúd disznót győz.
de akkor szóljatok már az összes sap/nav/exact fejlesztőnek, hogy ne használjon táblákat, hogy az importáláshoz olyan excel táblákat kell kitölteni, amik AW-ig vagy ébb BQ-ig tartanak, ugye az hány oszlop???egyébként:
"ÁFA osztály inkább tartozik a kategóriához, ha egy termék csak egy kategóriában lehet."
Normális vagy? nézz meg egy könyves áruház áfa listáját, még a térképek közt is van 5 meg 27%-os áfás termék is, tehát lehet ugyanabban a kategóriában símán több áfás termék, termékenként kell áfa osztályt megadni, tehát szerinted az nyerő, hogy a termék adatbázisban egy oszlop áfa helyett legyen egy külön tábla két oszloppal termékID,áfakulcs, az hol értelmes már???tökéletesen vezetve van ki mikor és mit módosított, a naplóban, amit vezet a rendszer, nem pedig máshol
akciók pedig símán összeköthetők ak ezdő és vég időponton keresztül, nem is értem a felvetést, miért ne lehetne?
sőt, automatikusan kezeli a listaárat, az eredeti árat (ha akciós ár időszakban van) az akciós időszakot, ha mennyiségi akció van háy darab felett hány százalék kedvezményt ad a rendszer és sorolhatnám..szállítási idő sem szállítótól függ, mert adott szállítón belül is van raktári, külső raktáros de hamar érkező, és az amit ő is rendel, így adott szállító adott termékcsoportjában sem azonos az idő
A címkékben igazat adok, csak "az úgy volt...." hogy utólag lett kitalálva anno, hogy kell, és így maradt
"Csík így hirtelen pongyolán ezek jutottak eszembe. A gond az, hogy elég lenne csak egy "ki mit csinált" kérdést feltenni a te szerkezetedhez, fel kellene tenned a kezed, hogy izé, az úgy volt."
Símán megmondom, miután teljes naplózás van, mint mondtam.fogalmatok nincs arról, ezen kívül hány és milyen táblával dolgozik a rendszer, a szerkezetét sem látjátok, csak a bedobott példára ráugrotok, mert hosszú volt az ünnep és jó valakit piszkálni.
Nem érdekel, kérem kimoderálni innen az összes beírásomat, aztán legyetek boldogok, hogy nem zavarok itt
nem érdekel igazán.persze, tegyek egy oszlopot külön táblába, csak azért, hogy mellé tehessem még egyszer a termékid-t, mert az jó? indok nincs, csak ködösítés. hogy csak azért szar, mert 30 oszlopos.
-
#1410
biker
nagyúr
Peter Kiss
#1408
biker
nagyúr
válasz
Peter Kiss
#1408
üzenetére
nem minden alkalmazás lényege a rugalmasság. ez is egy szempont, de nem mindenek feletti.
Ezen túl külön tábla csak azoknak jár, amit garantáltan többször felhasználunk és/vagy sűrűbben írjuk6olvassuk mint a termékek táblát (kategóriák, értékelések, statisztikák, kosárban lévő cikkek, korábban vásárolt cikkek, stb)
de mondd már meg, miért nem lehet egy táblában minden termék jellemző?
id, név, rövid leírás, hosszú leírás, cikkszám, szállítói kód, vonalkód, cimkék, kat_id, szállítási idő, áfa osztály, ára, akciós ára, akció eleje, akció vége, eredeti ára, és még fejből nem tudom, mik
te ezt szétdarabolnád? akkor minden darabolással egy redundáns termék_ID oszloppal hízlalod az adatbázist...martonx: nem arról volt szó, kinek az apukája erősebb, és kinek van több tapasztalata, hanem leírtam egy gyakorlati tapasztalatomat, ennyi.
-
#1407
biker
nagyúr
Peter Kiss
#1406
biker
nagyúr
válasz
Peter Kiss
#1406
üzenetére
akkor úgy mondom, nem eléggé látványosan gyorsít
egyébként igen, fulltext search miatt kell a match/against, és ez legalább relevancia szerint is tud rendezni, score-ra.
a 30+ oszlop nem tervezési hiba, max egy másik elv...ha van egy termék és 30 jellemzője, akkor mitől jobb 16 táblába szétpakolni és egy segédtáblába mondjuk összeszedni a jellemző><ID párokat, mint egy woocommerce féle webshop esetén?
nálam 150.000 termék 150.000 sor, a woocommerce a széthányt termékjellemzők miatt ugyan 4-5 oszloppal dolgozik, de 15.000 termék 670.000sort foglal el, és lassú mint egy halott disznó a jégen
-
#1405
biker
nagyúr
Peter Kiss
#1403
biker
nagyúr
válasz
Peter Kiss
#1403
üzenetére
Sima select/where felallast meg latvanyosan nem is gyorsit az index, tapasztalat
Match/against eseten igazan latvanyos, no meg kovetelmeny is mert csak indexbol dolgozik150.000 soros 30+ oszlopos 250megas tabla keresese index nelkul 6 oszlopra (termek nev, leiras, cimke, kategoria megjegyzes stb) 15-25mp
Index es select 2-5mp
Index 6 oszlopra es match against utan 0,01-0,06 sec, max 0,15 sec, erre mar mehetett a live search result box -
#1325
biker
nagyúr
Sk8erPeter
#1324
biker
nagyúr
válasz
Sk8erPeter
#1324
üzenetére
5385 sor érintett. ( a lekérdezés 0.0782 másodpercig tartott )
UPDATE users SET nev = LTRIM(nev); egész pontosan... -
biker
nagyúr
heeeelp
van egy 6000 nevet tartalmazó tábla.
ebből 5400 importkor rosszul került be, mert szóközzel kezdődik
nem [kovács béla] hanem [ kovács béla]
persze innentől borul a név szerinti rendezés (az új neveket már helyesen viszik fel)Hogyan lehet az első, és csak az első szóközt kiherélni paranccsal, mert félek, a kovács és a béla közti szóközt is cserélné
előre is köszi
-
#1215
biker
nagyúr
Brown ügynök
#1213
biker
nagyúr
válasz
Brown ügynök
#1213
üzenetére
ja, bocsi, tényleg
-
#1212
biker
nagyúr
Brown ügynök
#1211
biker
nagyúr
válasz
Brown ügynök
#1211
üzenetére
nincs it semmi gond, az 1-es termékből nem adtál el, ezért az null
a többiből igencsinálj egy harmadik oszlopot a selectbe, amiben a két oszlop különbsége van!
talán így működhet? (vessző kimaradt )SELECT i.product_id, SUM( i.quantity ) , SUM( d.quantity ), (SUM( i.quantity ) - SUM( d.quantity ) ) as diff
FROM `stock_intake_item` i
LEFT JOIN stock_deliver_item d ON d.product_id = i.product_id
GROUP BY i.product_id -
biker
nagyúr
nem ,bakker, hülye vagyok.
drop index, create indexNo, kipróbálom ezzel majd! köszi
Martonx: még nem eldöntött, hogy mysql vagy php probléma. MErt ha a mysql tudna importálni iso-8859-2 szöveget utf8-ba (és tud, hiszen a set names és a set character set ezt lehetővé teszi, bármilyen STRING bemenetnél) akkor nem lenne gond. De sajna a load data csv-ből dolgozik, nem input stringből, és itt nem működik a jelek szerint a fenti metódus.
Így lesz a mysql gondból php gond
-
biker
nagyúr
mondjuk nagyobb bajom, hogy ha a fulltext index előre be van állítva, és beimportálom a 180.000 sort, akkor csak 112-ezret importál be
erre a manual aztmondja, előre kapcsoljam ki az indexet, majd utólag új index, de ha a 180.000 sor be van tolva, akkor az indexelésnél hibát dob
#1034 error és 137-es hiba
erre a repair table sem megoldásMost itt szenvedek ezzel
-
biker
nagyúr
UTF8 kódolású táblába importálnék csv-ből, de ha nem utf8 a kódolása, hibás lesz
LOAD DATA LOCAL INFILE :file INTO TABLE ar_termekek CHARACTER SET UTF8 FIELDS TERMINATED BY ';' ENCLOSED BY '\"' LINES TERMINATED BY '\r\n' IGNORE 1 LINES SET bolt_id= :bolt_id, frissitve=NOW();hiába a character set utf8, ha latin2 a csv, akkor a mező első ékezetes karakterénél töri a mező tartalmát, pl kézi fólia, akkor k betű marad benne
Mi a megoldás?
-
#1080
biker
nagyúr
Sk8erPeter
#1079
biker
nagyúr
válasz
Sk8erPeter
#1079
üzenetére
ja, ugyanide jutottam én is
most egész kellemesen dobálja a találatokat gépelés közben. -
#1077
biker
nagyúr
Sk8erPeter
#1076
biker
nagyúr
válasz
Sk8erPeter
#1076
üzenetére
persze, alapvetően jó dolgok.
csak megtalálni az egyensúlyt az erőben, nehéz -
#1070
biker
nagyúr
Sk8erPeter
#1069
biker
nagyúr
válasz
Sk8erPeter
#1069
üzenetére
mikor a cimkefelhő még LIKE keresésekre ment rá, és jött a googlebot indexelni akkor végigpörgette azokat, termékenként 10-30 cimke, konkrétan 130.000 termékhez 1m feletti cimke, melyek random jelennek meg minden lap alján, ezért mindig változó tartalommal rágerjedt a bot rendesen) + a kereső mezőt is kezelte a bot, akkor 50-60.000 cikkig nem volt gond, aztán betoltuk a LÍRA 40.000 könyvét, és másnap letérdelt a site
és csak néztünk, mi a fene van?
egy keresés hirtelen 15mp lett, és mikor betelt a que akkor cumi, leállt a mysqlmost is megy, ez csak a googlebot(!!):
havi 370.000 keresési lekérdezés
22.000 kattintás1.403.400 egyedinek vélt oldal, amiből 620.000 indexelve (a keresett termékek is egyedi oldalon jelennek meg, becsapva a botot, + egyedi fejléc + egyedi keyword és description oldalak)
napi átlag 38.000 oldal feltérképezés (csúcs 68.000)
átlagos adatforgalom 850Megabyte (csúcs 1,6Giga) (gzipelés nélkül ez elment napi 4-5gigabyteba)
oldalak betöltési ideje átlag 852ms, csúcs 1,4s
(na ez ment át 25-30mp-be a várakozó lekérések miatt)Na ezt nem akarom feladni
-
#1068
biker
nagyúr
Sk8erPeter
#1067
biker
nagyúr
válasz
Sk8erPeter
#1067
üzenetére
mert nem szeretem, ha elérhetetlen az oldal, és ha elkezdi a user írni, átlagos mp-enkénti 2 karakter sebességgel a szöveget, hogy "fűrészlap" akkor az 6-7mp alatt 9 keresés, 9x0,2-0,3mp
ezt szorozzuk fel a napi 1200-1400 látogató oldalbetöltéseivel és keresésével, és kijön egy szép letérdelős oldal
Mint mikor régen másképp ment a kereső, és a google indexelte az oldalt az új cimkefelhővel, és naponta letérdelt az adatbázis emiattEzért alapértelmezett a kereső match-el indexelve, és csak az összetett keresőben tud a user olyat választani, hogy adott mezőkben szótöredékre keres
+ a LIKE lekérést nem lehet relevancia szerint rendezni, a match-ot meg lehet score-ba tenni és úgy megjeleníteni, és így a zsindelyes szőlő pálinka első találatot ad, míg LIKE esetén meg se találja, ha a név zsindelyes pálinka, szőlő
érted?
-
biker
nagyúr
match/against vs LIKE és keresési eredmény problémám van
Van egy termék adatbázis, abban egy kereső, sok féle kereséssel.
A helyes indexeléssel sajnos nem vagyok előrébb, mert a match az csak szó egyezésre keres. a like %% ugye töredékre is, de lassú, a query expansion meg szintén csak teljes szóra keres, de hasonló szavakra is, ami miatt túl sok eredményt ad vissza
130.000 rekord, 200M feletti a táblaméret
plforrasz > LIKE %% esetén kb 0,2s a keresés, és talál kb 300 terméket, forrazstásra
forrasz > MATCH 0 találat
forraszt > MATCH esetén már jobb, kb hasonló mint a LIKE, de 0,002s az eredményforrasz > match with query expansion továbbra is 0 találat
forraszt > match with query expansion 88.000 találat, minden ami forraszt, hegeszt, és sorolhatnám, ez meg túl sok, és nem releváns minden esetben, szótöredékre továbbra sem keresLétezik-e olyan MATCH AGAINST ami töredékre is keres?
De máshol ezzel semmi gond nincs. Szuper....
Új hozzászólás Aktív témák
Hirdetés
- Vicces képek
- Nyaralás topik
- Xbox Series X|S
- One otthoni szolgáltatások (TV, internet, telefon)
- Delta Force (2024)
- Sütés, főzés és konyhai praktikák
- lezso6: Nem látszik a kurzor Chrome alatt a beviteli mezőkben?
- Call of Duty: Black Ops 6
- Autós topik látogatók beszélgetős, offolós topikja
- Vezetékes FEJhallgatók
- További aktív témák...
- 127 - Lenovo Legion Pro 7 (16IRX9H) - Intel Core i9-14900HX, RTX 4080 (ELKELT)
- BESZÁMÍTÁS! ASUS ROG CROSSHAIR VI EXTREME alaplap garanciával hibátlan működéssel
- LG 65" C1 OLED - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - PS5 és Xbox Ready!
- Országosan a legjobb BANKMENTES részletfizetési konstrukció! Lenovo ThinkPad X13 Gen 5
- Motorola G72 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: Promenade Publishing House Kft.
Város: Budapest