Adatbázis: SQL, XML DB

A problémám a következő:
A sqlite like nem használja az indexet, ha számmal kezdődik a string.

teszt:

DROP TABLE IF EXISTS partners;
CREATE TABLE partners (id INTEGER PRIMARY KEY  NOT NULL , name TEXT NOT NULL );
INSERT INTO partners VALUES(1,'1 Próba');
INSERT INTO partners VALUES(2,'2 Próba');
INSERT INTO partners VALUES(3,'3 Próba');
CREATE INDEX hex_name_index ON partners ( hex(name) COLLATE NOCASE );

EXPLAIN QUERY PLAN SELECT name FROM partners WHERE hex(name) LIKE 'Foo%' ; 
      -> SEARCH TABLE partners USING INDEX hex_name_index (<expr>>? AND <expr><?)            //Ez jó !

EXPLAIN QUERY PLAN SELECT name FROM partners WHERE hex(name) LIKE '1Foo%'
      -> SCAN TABLE partners                                                     //Ez miért nem használja az indexet ?
  
select sqlite_version();
      -> 3.20.1

Nem a hex függvényt szeretném használni hanem egy saját determinisztikus függvényt, de a hiba ezzel is előjön.
Már mindent kipróbáltam, de sehogy sem tudom rábírni, hogy az indexet használja, ha számmal kezdődik a string.
Ha a tábla nevét így adom meg:"partners INDEXED BY hex_name_index" akkor "Likely SQL syntax error"-t dob a második esetben.

Ha valakinél működne akkor írja már meg a verziót
, előre is köszönöm.

update:
https://www.sqlite.org/optoverview.html#the_like_optimization
"There are many conditions on this optimization:"
....
"B. the right-hand side pattern argument does not begin with a minus sign ("-") or a digit."

Hello!
Eléggé idegen fogalom számomra a táblázat kezelés, szóval belefutottam egy olyan problémába ami kifog rajtam egyelőre, gondoltam írok ide hátha valaki tud rá megoldást.

Szóval van egy webshop aminek a kiexportált csv "adatbázisát" szeretném szerkeszteni táblázat kezelővel, jelenleg google sheets-el. Egy terméknek variálható ára van ami a méretétől függ, azaz S|M|L|XL...(táskákról van szó), ebből kifolyólag a táblázatban minden egyes termék bejegyzéshez tartoznia kéne plusz négy sornak amiben a különböző méretekhez tartozó árak/súly/stb. szerepel. Mivel elég sok termék van (jelenleg 1120 és ez még csak a kezdet) ezért szeretném ha ezt a 4 sort klónozni tudnám növekvő sorrendben és lényegében így megadni az összes terméknek a plusz négy tulajdonságát.
Egyszerűsített példa:

Megpróbáltam az alap legegyszerűbb módszert hogy kijelölöm a fenti példa alapján B2-B8-ig és utána elkezdem húzni lefelé, ez a módszer szépen működik ha csak két egymás alatt lévő cellát fogok össze és sorrendben vannak bennük számok.. pl. 1 és 2, utána szépen rakja ki sorrendben az értékeket, de itt ugye 4x2 egymás alatti cellát fogok össze és hát sehogy se működik a dolog, ha csak sima számokkal dolgozok, például 1,1,1,1 és 2,2,2,2 akkor a "generált" cellákban tört értéket kapok. Próbálkoztam pár egyszerűbb formulával .. például: ="Táska " & 1 vagy ="Táska " & ARRAYFORMULA(ROW(A2)-1) .. továbbra is sikertelenül.
Szóval valaki tud megoldást arra hogy tudnék négy egymás alatt lévő hasonló tartalmú cellákat növelni négyesével, azaz 1,1,1,1 aztán 2,2,2,2 majd 3,3,3,3 és így tovább.
Ha valaki veszi a fáradságot hogy válaszoljon azt előre is köszönöm!

Sziasztok.
Úgy tűnik nem vagyunk barátok az SQL-lel. Csináltam egy lekérdezést, a végeredmény ugyan jó, de elképesztően nem hatékony :

WITH pl AS (SELECT * FROM phs_links WHERE phs_link_type2 = 'Front' AND port_id2 = ?)
SELECT pll.*, plr.*, ppr.*
FROM pl AS pll
JOIN interfaces AS il ON pll.port_id1 = il.port_id
JOIN mactab AS m ON il.hwaddress = m.hwaddress
JOIN phs_links AS plr ON m.port_id = plr.port_id1
JOIN pports AS ppr ON plr.port_id2 = ppr.port_id
WHERE min_shared(plr.port_shared, ?::portshare) <> 'NC'::portshare

(Az adatbázis : http://svn.kkfk.bgf.hu/lanview2.doc/database/lanview2.html )
Az első SELECT (a WITH után) egy, vagy két rekordot ad vissza (elvileg max. 4-et), a végeredmény pedig legfeljebb egy rekord.
A min_share() függvényben vannak RAISE INFO parancsok, és ebből az látszik, hogy az SQL szerver egy SELECT-et gyárt az egészből,
és minden rekordra végrehajtja az összes feltételt. Vagyis a min_share() által kezdeményezett kiírás az általam becsült 1-2 helyett,
több százszor-ezerszer jelenik meg.
Lehet ezt a lekérdezést valahogy optimalizálni.
Direkt azért írtam meg a SELECT-et két lépésben, mert szerintem így gyorsabb(-nak kéne lennie) , de úgy tűnik valamit már megint félreértettem.

Sziasztok,

MySQL-ben lehet létrehozni in-memory táblákat, melyek tartalma elvész mysql server újraindítása után. Pont ez kellene.

Viszont mysqldump kinyomja az in-memory táblák tartalmát is.

Hogyan tudnék olyan mysqldump parancsot írni, amely nem dump-olja ki a memory engine-es táblák tartalmát vajon?

Köszi.

Üdv!

Egy nagyon régi problémámhoz hasonló jött most elő, és sajnos ehhez egyáltalán nem értek.

Adott egy python + django applikáció, ami mögött egy mysql szerver található. Az adatbázisban semmilyen kódolás nem lett beállítva, default szinte teljesen.

Az őűŐŰ karakterek helyett mindenhol kérdőjelek jelennek meg, és ezt szeretném orvosolni.

Nagyjából 4- 5 tábláról van szó, de ha az adatbázis egészére meg lehet oldani, az még jobb.

Amit eddig próbáltam:

ALTER TABLE tablanev CONVERT TO CHARACTER SET utf8 COLLATE utf8_hungarian_ci

. Ez megoldja a problémát az újonnan felvitt rekordokhoz, de a régiek helyén kérdőjelek maradnak. Ha ráfrissitek a rekordra, szintén kérdőjelek maradnak. Igazából nem tudom, hogy ezek milyen típusú kérdőjelek (mármint tényleg kérdőjelek (#63), avagy még megvan az eredeti karakter (őúŐÚ, stb), csak rosszul jelennek meg).

select mezo from table

hatasara is kerdojelnek tunnek.

-----

Debian: 8.9
Mysql: 5.5.57
Python: 2.7.9
Django: 1.11.4

mysql> show session variables like 'char%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | latin1                     |
| character_set_filesystem | binary                     |
| character_set_results    | utf8                       |
| character_set_server     | latin1                     |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.00 sec)

Koszonom a valaszokat, hozzaszolasokat.

Sziasztok!

Küzdök egy problémával, felteszem itt is, hátha tudtok segíteni.
A feladat, hogy egy megrendeléshez az ügyfél könnyen megjegyezhető, de egyedi megrendelésazonosítót kapjon. Ehhez MySQL-t használnék, mert hogy az van. Viszont nem értek hozzá.

Amit elkövettem (és lokálisan, USB WEB Server-el működik is) az a következő SQL script:

CREATE TABLE IF NOT EXISTS `orders` (
`ID` int(11) NOT NULL AUTO_INCREMENT,
PRIMARY KEY (`ID`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_hungarian_ci AUTO_INCREMENT=1 ;

DELIMITER $$

CREATE FUNCTION `get_next_id`() RETURNS int(11)
BEGIN
DECLARE ID INT(11);

delete from orders;

insert into orders (ID) values (0);

SELECT LAST_INSERT_ID() INTO ID;

RETURN (ID);
END$$

DELIMITER ;

A cél, hogy a get_next_id függvény visszaadjon az előzőnél eggyel nagyobb értéket.
Viszont a függvény scriptjének futtatásakor a következő hibaüzenetet kapom:

#1418 - This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)

A neten talált "SET GLOBAL log_bin_trust_function_creators = 1;" megoldás nem jó, nincs hozzá meg a jogosultság.

Mit tehetek esetleg, hogy működjön, amit szeretnék?

Gábor

Üdv;

-nagyon béna vagyok ehhez :(
-adott 3 tábla: dolgozo, dolgozo_szla, szamfejtes; dolgozoban: Id, Nev; dolgozo_szlaban: ID, DolgozoID; a szamfejtesben: dolgozo_szlaID, fizetés;
-a dolgozo_szla kapcsolja össze a kettőt és kellene egy olyan lekérdezés, ami Név, fizetés párokat dob;
-pl. dolgozo (47, zumy) dolgozo_szla (27,47) szamfejtes (27,50000) ; ebből kellene: zumy 50000

-tudom, h ez nagyon alap, de sehogy se jön össze; ill. csak sima sql parancsok játszanak

Előre is köszönöm!

zümy

Debian 9 alatt a mariadb root hozzáférésének a jelszavát szeretném beállítani, de sehogyan sem megy. Próbáltam a

mysqladmin -u root password ujJelszoAmitSzeretnek

paranccsal, de közvetlenül a mysql.user táblába írva is:

USE mysql;
UPDATE user SET password=PASSWORD('ujJelszoAmitSzeretnek') WHERE User='root' AND Host = 'localhost';
FLUSH PRIVILEGES;

Mindkét parancs ugyanúgy változtatja a mysql.user táblát, tehát olyan, mintha megtörténne a beállítás, ám mégsem.
Bármit is állítok, bárhogyan, továbbra is jelszó nélkül tudok belépni a root felhasználóval.
- FLUSH PRIVILEGES megvolt.
- mysql reload megvolt.
- mysql restart.
- Rendszer restart is megvolt.
- Még frissítettem is mindent, de továbbra sem kér jelszót.
Végignéztem a /etc/mysql és az /etc/init.d/mysql-t is, hátha valahol van egy skip-grant-tables, de sehol semmi.
Biztos, valami nagyon alapot nézek be, de nem találom, és sehogyan sem tudok jelszót adni a root felhasználónak.

Van egy ilyesmi tablam:

MariaDB [clapf]> show create table token;
+-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table |
+-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| token | CREATE TABLE `token` (
`token` bigint(20) unsigned NOT NULL,
`uid` smallint(5) unsigned NOT NULL DEFAULT 0,
`nham` int(11) DEFAULT 0,
`nspam` int(11) DEFAULT 0,
`timestamp` int(10) unsigned DEFAULT 0,
KEY `token_idx1` (`token`),
KEY `token_idx2` (`uid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

A 10.2-es mariadb hoszton az alabbi select explain eredmenyt kapom:

MariaDB [clapf]> explain SELECT token, nham, nspam FROM token WHERE token in (13036551635545399192,5805177638834534979,5887110958975549203,48491888334302022) and uid=0;
+------+-------------+-------+-------+-----------------------+------------+---------+------+------+------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+-------+-------+-----------------------+------------+---------+------+------+------------------------------------+
| 1 | SIMPLE | token | range | token_idx1,token_idx2 | token_idx1 | 8 | NULL | 4 | Using index condition; Using where |
+------+-------------+-------+-------+-----------------------+------------+---------+------+------+------------------------------------+
1 row in set (0.00 sec)

A db-t kidumpoltam, attettem egy 10.3-as mariadb hosztra, ami viszont ugyanerre select-re egeszen mast ad vissza:
MariaDB [clapf]> explain SELECT token, nham, nspam FROM token WHERE token in (13036551635545399192,5805177638834534979,5887110958975549203,48491888334302022) and uid=0;
+------+-------------+-------+------+-----------------------+------------+---------+-------+--------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+-------+------+-----------------------+------------+---------+-------+--------+-------------+
| 1 | SIMPLE | token | ref | token_idx1,token_idx2 | token_idx2 | 2 | const | 837534 | Using where |
+------+-------------+-------+------+-----------------------+------------+---------+-------+--------+-------------+

Ennek megfeleloen (a full table scan-nek hala) sokkal tovabb tart, mig a select eredmenyet megkapom.

Meg annyi erdekesseg, hogy a 10.2 es 10.3 optimizer_switch valtozoja csak abban ter el, hogy 10.3-on meg a split_materialized=on is benne van.

A show index from token mindket helyen ugyanazt adja vissza:

show index from token;
+-------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| token | 1 | token_idx1 | 1 | token | A | 1675388 | NULL | NULL | | BTREE | | |
| token | 1 | token_idx2 | 1 | uid | A | 2 | NULL | NULL | | BTREE | | |
+-------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+

A kerdesem ezek utan csak annyi, hogy wtf?

Sziasztok,

A helyzetet a következő:
Van kb 150Gb teszt input data amit a nightly CI futás használ.
Zip fájlok, bennük képek és számítási kalkulációk.
A zip fájlok átlagos mérete 80-100Mb között mozog.
Évente kb 50 Gb-tal fog növekedni a szükséges hely a beérkező új .zip-ek miatt.
Jelenleg Windows File Share-n vannak.
Naponta kb 2x van "kiolvasás" tehát cca 300Gb network transfert indukálunk/nap

Keresek:
Egy olyan megoldást amiben ha lehet verzóizva tudom tárolni a zip fájlokat (ha szüksége lenne rá)
Gyorsan elérhető. (Nem hal bele ha listázom a fájlokat és nem gondolkozik tul sokat :-)).

Jelenleg a JFrog Artifactory-t látom befutónak de elég szűkek az ismereteim szóval érdeklődnék kinek milyen tapasztalata, esetleg megoldása van a témára (Talán Big Data háttérrel rendelkező kollégák tudnak valami jó tool-t :-)))