Lange tekster i et felt - hvordan indstiller jeg?

[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å
http://www.danacordbutik.dk/product_info.php?products_id=42806

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)
--
Venlig hilsen
Kurt Hansen

[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å
> http://www.danacordbutik.dk/product_info.php?products_id=42806

Rettelse: eksemplet er i stedet denne, som burde vise 14 CD'er
http://www.danacordbutik.dk/product_info.php?products_id=42806

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?

[Dennis Munding]

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"...


--
Med venlig hilsen

Dennis Munding

---
Denne mail er kontrolleret for vira af AVG.
http://www.avg.com

[Kurt Hansen]

Den 16/07/2017 kl. 10.10 skrev Dennis Munding:
> Kurt Hansen wrote:
>
>> Jeg bruger en ældre webshop som er baseret på osCommerce. Databasen

>> 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å
>> http://www.danacordbutik.dk/product_info.php?products_id=42806

> 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.
http://www.danacordbutik.dk/product_info.php?products_id=42806
indeholder 118.282 tegn.

[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.
> http://www.danacordbutik.dk/product_info.php?products_id=42806
> 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(?).

[Jan Hansen]

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
<https://mariadb.com/kb/en/mariadb/data-type-storage-requirements/#string-
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.



--
mvh Jan.
Help Microsoft stamp out piracy. Give
Linux to a friend today!

[Arne Vajhøj]

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

Arne

[Arne Vajhøj]

On 7/16/2017 6:13 AM, Jan Hansen wrote:
> 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.
>>> http://www.danacordbutik.dk/product_info.php?products_id=42806
>>> 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.

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

[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.

[Jan Hansen]

Du har ret. De 118.649 bytes burde nemt kunne være der, hvis det var
MEDIUMTEXT til at begynde med...

[Arne Vajhøj]

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

[Krabsen]

Du bør i øvrigt kigge lidt på andre dele af sitet også..

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

http://www.danacordbutik.dk/contact_us.php

/ :-)

[Kurt Hansen]

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.

[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.
http://www.danacordbutik.dk/product_info.php?products_id=41416

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.

[Dennis Munding]

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!

[Kurt Hansen]

Den 17/07/2017 kl. 23.00 skrev Dennis Munding:
> Kurt Hansen wrote:
>
>> 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 :-(
>>>
>>> http://www.danacordbutik.dk/contact_us.php
>>>
>>> / :-)
>>
>> 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).

Sikkert, men udvikleren har stoppet sine aktiviteter, så rettelser er
ikke en mulighed.

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

Godt skuldret, du gamle (jeg er selv 63) :-)

[Dennis Munding]

"Intet er umuligt for den, som bærer viljen i hjertet..." ;-)

Det er et spørgsmål om at lokalisere det script, som udfører
formular-tjekket og derefter sender mailen samt modificere koden bag
kontakt-siden. :-)


Jeg tilhører så en noget yngre årgang... :-)

[Kurt Hansen]

Den 18/07/2017 kl. 19.13 skrev Dennis Munding:
> Kurt Hansen wrote:
>
>> Den 17/07/2017 kl. 23.00 skrev Dennis Munding:
>>> Kurt Hansen wrote:
>>>
>>> Mit gæt er manglende sikring mod injection (eksekvering af kode via
>>> en formular på siden).
>>
>> Sikkert, men udvikleren har stoppet sine aktiviteter, så rettelser er
>> ikke en mulighed.
>>
>>> Oplevede det samme i mine "unge" år i dette univers.
>>> Men jeg valgte at tage kampen op mod idioterne og vandt!
>>
>> Godt skuldret, du gamle (jeg er selv 63) :-)

> "Intet er umuligt for den, som bærer viljen i hjertet..." ;-)
>
> Det er et spørgsmål om at lokalisere det script, som udfører
> formular-tjekket og derefter sender mailen samt modificere koden bag
> kontakt-siden. :-)

Scriptet hedder såmænd "contact_us.php".

Vi har også oplevet at "Tell a friend" blev misbrugt, så den er disablet.

[Dennis Munding]

Kurt Hansen wrote:

> Den 18/07/2017 kl. 19.13 skrev Dennis Munding:
> > Kurt Hansen wrote:
> >
> > > Den 17/07/2017 kl. 23.00 skrev Dennis Munding:
> > > > Kurt Hansen wrote:
>
> > "Intet er umuligt for den, som bærer viljen i hjertet..." ;-)
> >
> > Det er et spørgsmål om at lokalisere det script, som udfører
> > formular-tjekket og derefter sender mailen samt modificere koden bag
> > kontakt-siden. :-)
>
> Scriptet hedder såmænd "contact_us.php".

Så er det bare at sørge for, at tjekke alle inputs for evt. tags og
udskrive en fejlmelding, hvis indtastningerne er ugyldige. :-)

> Vi har også oplevet at "Tell a friend" blev misbrugt, så den er
> disablet.

Ja, den mulighed lærte jeg ret hurtigt at udelade, takket være et par
årvågne sjæle herinde. :-)

[Kurt Hansen]

Den 19/07/2017 kl. 08.51 skrev Dennis Munding:
> Kurt Hansen wrote:
>
>> Den 18/07/2017 kl. 19.13 skrev Dennis Munding:
>>> Kurt Hansen wrote:
>>>
>>>> Den 17/07/2017 kl. 23.00 skrev Dennis Munding:
>>>>> Kurt Hansen wrote:
>>
>>> "Intet er umuligt for den, som bærer viljen i hjertet..." ;-)
>>>
>>> Det er et spørgsmål om at lokalisere det script, som udfører
>>> formular-tjekket og derefter sender mailen samt modificere koden bag
>>> kontakt-siden. :-)

>> Scriptet hedder såmænd "contact_us.php".
>
>
> Så er det bare at sørge for, at tjekke alle inputs for evt. tags og
> udskrive en fejlmelding, hvis indtastningerne er ugyldige. :-)

PhP er ikke noget man bare gør, hvis man ikke har forstand på det ;-)

[Dennis Munding]

Nej, men det er utroligt, hvad man kan finde af viden på internettet og
muligheder for at få hjælp... ;-)

[Kurt Hansen]

Den 20/07/2017 kl. 08.31 skrev Dennis Munding:
> Kurt Hansen wrote:
>
>> Den 19/07/2017 kl. 08.51 skrev Dennis Munding:
>>
>>>> Scriptet hedder såmænd "contact_us.php".
>>>
>>>
>>> Så er det bare at sørge for, at tjekke alle inputs for evt. tags og
>>> udskrive en fejlmelding, hvis indtastningerne er ugyldige. :-)
>>
>> PhP er ikke noget man bare gør, hvis man ikke har forstand på det ;-)

> Nej, men det er utroligt, hvad man kan finde af viden på internettet og
> muligheder for at få hjælp... ;-)

Ja, men ikke på Usenet forstår jeg ;-)

P.S. Bemærk smileyen.

[Dennis Munding]

HVis nu du stillede dit spørgsmål vedr. php i den rigtige gruppe, så er
jeg ret sikker på, at du nok skal få hjælp... ;-)

[Jørn Andersen]

On Sun, 16 Jul 2017 09:56:53 -0400, Arne Vajhøj <ar...@vajhoej.dk>
wrote:

<snip>

>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.

<snip>

Som en meget generel betragtning kan jeg godt være enig.

Men hvordan vil du gemme ustruktureret tekst (artikler eller som i
dette tilfælde: en vare-beskrivelse) i en database?

Hvis en artikel fx indeholder tekst, hvor noget er i kursiv, eller der
er overskrifter, mellemrubrikker, lister osv. – er det så ikke
nødvendigt at gemme tekst og formattering sammen?

Eller hvad med artikler med indsatte billeder. Det kunne man løse ved
at indsætte en placeholder. Men er der den store forskel på et HTML
IMG-tag og en hjemmelavet placeholder for et billede?

Kort sagt: Jeg mener ikke altid reglen kan overholdes :-)

Men jeg er meget åben for måder, som jeg måske ikke har tænkt på??


Mvh. Jørn

--
Jørn Andersen
http://socialister.dk
http://marxisme.dk

[Arne Vajhøj]

Det bedste ville være at gemme data struktureret i flere felter og så
vise hvert felt på en præsentations lags specifik måde.

Hvis varebeskrivelser er meget systematiske, så bør det kunne
lade sig gøre for dem.

Artikler er nok mere problematiske, da der ikke er samme
fordel i en systematisk struktur for dem.

Så der er nogle tilfælde hvor man har meget ustrukturerede
data.

Der ville jeg nok gemme data i et XML format, bruge
XSLT til at konvertere til præsentations format
som f.eks. HTML og udelukkende bruge class i HTML
output med ref til ekstern CSS fil.

Det vil gøre det muligt at understøtte andet
præsentations format end HTML inklusive data
eksport til andre systemer.

Det vil også gøre det nemmere at håndtere store ændringer
i web site layout inklusive skift i brugt HTML standard,
da sådanne kan håndteres i XSL uden at skulle rette i data.

Og jeg vil foretrække XML fremfor et hjemmelavet ML, p.g.a.
support (libraries, skills, tools).

Arne