ezz > edb.* > edb.database

 #1  
16.07.2017, 07:28
Kurt Hansen
Jeg bruger en ældre webshop som er baseret på osCommerce. Databasen
kører på mySQL. Jeg et felt som indeholder varebeskrivelse og for visse
CD'er (vi sælger klassisk musik) er indholdsfortegnelsen i
varebeskrivelsen så lang, at kun halvdelen bliver vist.

Feltet products_description står p.t. til MEDIUMTEXT. Jeg har forsøgt at
ændre til f.eks. VARCHAR med en længde på 65.535, men så siger den at
max. uden blobs er 65.535 - præcist det jeg har sat den til. Det forstår
jeg derfor ikke og efter at have skiftet blandt de forskelige muligheder
og er gået tilbage til MEDIUMTEXT viser den ikke så meget som før.
Tidligere blev der vist til og med CD7, mens det nu kun viser t.o.m. CD4 på
[..]

Jeg er også i tvivl om hvorvidt det er en god ide, selv om det skulle
lykkes. Shoppen indeholder 36.684 varer og det er kun et fåtal der har
så lange beskrivelser. Bliver shoppen/databasen ikke langsommere?

Server OS: Linux 3.10.0-614.10.2.lve1.4.50.el7.x86_64
Database: MySQL 5.5.5-10.1.25-MariaDB
HTTP Server: Apache
PHP Version: 5.6.30 (Zend: 2.6.0)
 #2  
16.07.2017, 08:40
Kurt Hansen
Den 16/07/2017 kl. 07.28 skrev Kurt Hansen:
> Jeg bruger en ældre webshop som er baseret på osCommerce. Databasen
> kører på mySQL. Jeg et felt som indeholder varebeskrivelse og for visse
> CD'er (vi sælger klassisk musik) er indholdsfortegnelsen i
> varebeskrivelsen så lang, at kun halvdelen bliver vist.
> Feltet products_description står p.t. til MEDIUMTEXT. Jeg har forsøgt at
> ændre til f.eks. VARCHAR med en længde på 65.535, men så siger den at
> max. uden blobs er 65.535 - præcist det jeg har sat den til. Det forstår
> jeg derfor ikke og efter at have skiftet blandt de forskelige muligheder
> og er gået tilbage til MEDIUMTEXT viser den ikke så meget som før.
> Tidligere blev der vist til og med CD7, mens det nu kun viser t.o.m. CD4 på
> [..]


Rettelse: eksemplet er i stedet denne, som burde vise 14 CD'er
[..]

Jeg kunne ikke forstå hvorfor der ikke blev vist noget mere tekst, når
jeg ændrede til LONGTEXT. Jeg fedtmulede og fandt ud af, at feltet i
databasen var klippet, hvilket egentlig er logisk nok.

Jeg måtte sætte hele teksten ind igen og nu bliver det hele vist.

> Jeg er også i tvivl om hvorvidt det er en god ide, selv om det skulle
> lykkes. Shoppen indeholder 36.684 varer og det er kun et fåtal der har
> så lange beskrivelser. Bliver shoppen/databasen ikke langsommere?


Ikke mærkbart, men der er vel nogle ulemper, eller hvad?
 #3  
16.07.2017, 10:10
Dennis Munding
Kurt Hansen wrote:

[..]
> [..]
> Jeg er også i tvivl om hvorvidt det er en god ide, selv om det skulle
> lykkes. Shoppen indeholder 36.684 varer og det er kun et fåtal der
> har så lange beskrivelser. Bliver shoppen/databasen ikke langsommere?
> Server OS: Linux 3.10.0-614.10.2.lve1.4.50.el7.x86_64
> Database: MySQL 5.5.5-10.1.25-MariaDB
> HTTP Server: Apache
> PHP Version: 5.6.30 (Zend: 2.6.0)


Undskyld mig, men vil du dermed påstå, at en max-længde på 65.535 tegn
ikke er nok til en varebeskrivelse?!?

Det svarer til mere end 40 maskinskrevne A4-sider!!??

Jeg plejer at bruge "text" til felter, som fordrer lange tekster og jeg
er endnu ikke stødt mod muren kaldet "overload"...
 #4  
16.07.2017, 11:21
Kurt Hansen
Den 16/07/2017 kl. 10.10 skrev Dennis Munding:
> Kurt Hansen wrote:


> Undskyld mig, men vil du dermed påstå, at en max-længde på 65.535 tegn
> ikke er nok til en varebeskrivelse?!?
> Det svarer til mere end 40 maskinskrevne A4-sider!!??
> Jeg plejer at bruge "text" til felter, som fordrer lange tekster og jeg
> er endnu ikke stødt mod muren kaldet "overload"...


Det er senere gået op for mig, at der før var sat til TEXT og ikke
MEDIUMTEXT som jeg skrev. Den er nu sat til MEDIUMTEXT.

Jeg er ikke kompetent til at påstå noget som helst, men databasen
fortæller mig at f.eks.
[..]
indeholder 118.282 tegn.
 #5  
16.07.2017, 11:51
Kurt Hansen
Den 16/07/2017 kl. 11.21 skrev Kurt Hansen:

> Jeg er ikke kompetent til at påstå noget som helst, men databasen
> fortæller mig at f.eks.
> [..]
> indeholder 118.282 tegn.


Det skal siges at produktbeskrivelsen er i HTML-format og derfor tælles
tags/koder vel med i optællingen af tegn(?).
 #6  
16.07.2017, 12:13
Jan Hansen
Kurt Hansen skrev Sun, 16 Jul 2017 11:51:48 +0200:

> Den 16/07/2017 kl. 11.21 skrev Kurt Hansen:
>> Jeg er ikke kompetent til at påstå noget som helst, men databasen
>> fortæller mig at f.eks.
>> [..]
>> indeholder 118.282 tegn.

> Det skal siges at produktbeskrivelsen er i HTML-format og derfor tælles
> tags/koder vel med i optællingen af tegn(?).


Jeg prøvede at hente det table med varebeskrivelsen, det fylder 118.649
bytes når jeg gemmer i utf8, så jeg tog nok et par linier for meget med.

Det indeholder 1032 gange smøren ' style="height:15.0pt" height="15"',
kan det ikke stå én gang i en css-fil i stedet for? height i css skulle
virke i explorer fra version 4.
Når jeg klipper det væk er der 83.561 bytes tilbage.

Så er der en hel masse indrykning. Det er muligt, at indrykning gør det
fint og overskueligt, men det er vel en pladeshop og ikke en html
nybegynderguide. Uden indrykning kommer det ned på 55.387 bytes, og
passer dermed i MEDIUMTEXT.

Forskellen mellem MEDIUMTEXT og LONGTEXT er 1 byte ifølge
<[..]
data-types>
det vil sige 36.684 bytes for hele shoppen, det burde ikke give den store
hastighedsforringelse.

PS. Er samtlige numre på products_id=42724 cover versioner af første
nummer på products_id=42606 ? De lyder ret ens.
 #7  
16.07.2017, 15:51
Arne Vajhøj
On 7/16/2017 5:51 AM, Kurt Hansen wrote:
> Den 16/07/2017 kl. 11.21 skrev Kurt Hansen:
>> Jeg er ikke kompetent til at påstå noget som helst, men databasen
>> fortæller mig at f.eks.
>> [..]
>> indeholder 118.282 tegn.

> Det skal siges at produktbeskrivelsen er i HTML-format og derfor tælles
> tags/koder vel med i optællingen af tegn(?).


Ja. MySQL gør ikke forskel udfra hvad tegnene indeholder. :-)

Arne
 #8  
16.07.2017, 15:56
Arne Vajhøj
On 7/16/2017 6:13 AM, Jan Hansen wrote:
> Kurt Hansen skrev Sun, 16 Jul 2017 11:51:48 +0200:
> Jeg prøvede at hente det table med varebeskrivelsen, det fylder 118.649
> bytes når jeg gemmer i utf8, så jeg tog nok et par linier for meget med.
> Det indeholder 1032 gange smøren ' style="height:15.0pt" height="15"',
> kan det ikke stå én gang i en css-fil i stedet for? height i css skulle
> virke i explorer fra version 4.
> Når jeg klipper det væk er der 83.561 bytes tilbage.


Det vil både spare plads *og* være et bedre design.

Nu bruger OP jo osCommerce og jeg ved ikke om det er muligt i den
kontekst, men generelt bør det slet ikke gemmes HTML eller CSS sammen
med data.

> Så er der en hel masse indrykning. Det er muligt, at indrykning gør det
> fint og overskueligt, men det er vel en pladeshop og ikke en html
> nybegynderguide. Uden indrykning kommer det ned på 55.387 bytes, og
> passer dermed i MEDIUMTEXT.


Du mener TEXT.

:-)

TINYTEXT : 255
TEXT : 64K-1
MEDIUMTEXT : 16M-1
LONGTEXT : 4 GB-1

Arne
 #9  
16.07.2017, 18:41
Kurt Hansen
Den 16/07/2017 kl. 15.56 skrev Arne Vajhøj:

> On 7/16/2017 6:13 AM, Jan Hansen wrote:
>> Det indeholder 1032 gange smøren ' style="height:15.0pt" height="15"',
>> kan det ikke stå én gang i en css-fil i stedet for? height i css skulle
>> virke i explorer fra version 4.
>> Når jeg klipper det væk er der 83.561 bytes tilbage.

> Det vil både spare plads *og* være et bedre design.


> Nu bruger OP jo osCommerce og jeg ved ikke om det er muligt i den
> kontekst, men generelt bør det slet ikke gemmes HTML eller CSS sammen
> med data.


Hvad mener du helt specifikt med "sammen med"? Nej, naturligvis ikke et
et felt med f.eks. stregkodenummer, eller varens pris, men i OSC er der
visse felter som er skabt til netop design med HTML og CSS, her iblandt
varebeskrivelsen. Indholdet af disse lagres derfor isoleret i det
pågældende felt i databasen.
 #10  
16.07.2017, 18:43
Jan Hansen
Arne Vajhøj skrev Sun, 16 Jul 2017 09:56:53 -0400:

> On 7/16/2017 6:13 AM, Jan Hansen wrote:
> Det vil både spare plads *og* være et bedre design.
> Nu bruger OP jo osCommerce og jeg ved ikke om det er muligt i den
> kontekst, men generelt bør det slet ikke gemmes HTML eller CSS sammen
> med data.
> :-)
> TINYTEXT : 255 TEXT : 64K-1 MEDIUMTEXT : 16M-1 LONGTEXT : 4 GB-1
> Arne


Du har ret. De 118.649 bytes burde nemt kunne være der, hvis det var
MEDIUMTEXT til at begynde med...
 #11  
16.07.2017, 22:34
Arne Vajhøj
On 7/16/2017 12:41 PM, Kurt Hansen wrote:
> Den 16/07/2017 kl. 15.56 skrev Arne Vajhøj:
>> Hvad mener du helt specifikt med "sammen med"? Nej, naturligvis ikke et

> et felt med f.eks. stregkodenummer, eller varens pris, men i OSC er der
> visse felter som er skabt til netop design med HTML og CSS, her iblandt
> varebeskrivelsen. Indholdet af disse lagres derfor isoleret i det
> pågældende felt i databasen.


Ja. Og det er efter min mening en rigtigt dårlig måde at gøre
det på. Data og præsentationen af data er to forskellige ting
og bør behandles som sådan.

Nu er det jo (som jeg delvist forventede) ikke dit valg, men
OSC's valg. Og derfor kan du ikke gøre noget ved det.

Men efter min vurdering stadig værd at nævne.

Arne
 #12  
17.07.2017, 08:58
Krabsen
Du bør i øvrigt kigge lidt på andre dele af sitet også..

Det er lidt pinligt, at siden 'Kontakt' ikke findes :-(

[..]

/ :-)
 #13  
17.07.2017, 10:47
Kurt Hansen
Den 17/07/2017 kl. 08.58 skrev Krabsen:
> Du bør i øvrigt kigge lidt på andre dele af sitet også..
> Det er lidt pinligt, at siden 'Kontakt' ikke findes :-(
> [..]
> / :-)


Det skyldes at "contact_us.php" er blevet hacket og bliver misbrugt. jeg
har aldrig haft tid til at finde ua af hvordan jeg fjerner punktet på siden.
 #14  
17.07.2017, 15:16
Kurt Hansen
Den 16/07/2017 kl. 07.28 skrev Kurt Hansen:
> Jeg bruger en ældre webshop som er baseret på osCommerce. Databasen
> kører på mySQL. Jeg et felt som indeholder varebeskrivelse og for visse
> CD'er (vi sælger klassisk musik) er indholdsfortegnelsen i
> varebeskrivelsen så lang, at kun halvdelen bliver vist.


Jeg har nu strippet en af de lange for overflødige HTML-koder. Det er en
box med 32 CD'er og nu fylder den kun 145.694 tegn.
[..]

Der er altså rigelig plads i MEDIUMTEXT.

Til efteråret udsender Deutsche Grammophon et rugbrød med Herbert von
Karajans samlede indspilninger for selskabet.
Den bliver med 330 CD'er ;-)

Tak for de mange input i denne tråd.
 #15  
17.07.2017, 23:00
Dennis Munding
Kurt Hansen wrote:

> Den 17/07/2017 kl. 08.58 skrev Krabsen:
> Det skyldes at "contact_us.php" er blevet hacket og bliver misbrugt.
> jeg har aldrig haft tid til at finde ua af hvordan jeg fjerner
> punktet på siden.


Mit gæt er manglende sikring mod injection (eksekvering af kode via en
formular på siden).

Oplevede det samme i mine "unge" år i dette univers.
Men jeg valgte at tage kampen op mod idioterne og vandt!

Lignende emner