[c#]HTML encoden -> veldlengte te klein/onjuist

[mOrPhie]

Ter intro: Ik programmeer het in c#, maar eigenlijk is het best algemeen.

Het probleempje:
Ik ben bezig met een webapplicatie. Deze applicatie heeft een form waar je spulletjes in kan voeren en zoals bij elke webapplicatie zorg je dat HTML Special-characters worden omgezet naar HTML-waardes (< wordt "<").

Ik heb er toen om performance-redenen voor gekozen om bij de invoer naar de database, de text al te encoden. Echter zit je dat met het volgende probleem: Het aantal tekens dat het veld ontvangt wordt effectief kleiner. Het teken "<" is maar 1 teken groot, maar omgezet ("<") is dit 4 tekens. 2 van zulke tekens maken een varchar( 8 ) dus al vol.

Nu denk ik erover om gewoon de "<" in de database te zetten en bij het ophalen terug/om te zetten. Buiten het feit dat je dan de optie voor een Fat-Client open houdt en de database clean houdt van html-chars, denk ik nu dat de performance (gezien het aantal users) er misschien niet eens zo onder te lijden zal hebben. Dus daar is niet zo'n twijfel over.

Maar toch was ik benieuwd. Zijn er mensen die mijn eerste optie wel 'ns geimplementeerd hebben en toen tegen dit probleem aan liepen en hier een oplossing voor vonden? Ik meen me te herinneren, dat "React" dat ook zo doet, dus Chem als je in de buurt bent

[ Voor 10% gewijzigd door mOrPhie op 02-01-2003 15:56 ]

[drm]

Je bedoelt dat een veld bijvoorbeeld 8 characters mag bevatten volgens de data-dictionary, zeg maar, en dat je dat in je dbms ook zo vaststelt, maar vervolgens tegen het probleem aanloopt dat 't bij 2x < vol is?

Je zou aan je constraint kunnen twijfelen, dan. Zeg je "'t veld mag 8 ascii karakters bevatten" of "'t veld mag 8 html karakters bevatten"... Da's in feite een wezenlijk verschil (dat blijkt )

[Buzzman]

Of je vangt je constraint in je website-logica af, ipv in je database

[EfBe]

je tekst in 2 velden bewaren in de database: 1 hoe het is ingevoerd, handig voor editen en 1 met de HTML encoded text. Maak dat 2e veld 'text' en je hebt variabele lengte ingebouwd in de database en het maakt dus niet uit of de text effectief langer wordt door encoding. Je viewt alleen de HTML encoded text en edit dus het andere veld. Wanneer iemand klaar is met editen, html encode je de text en de output zet je in het 'text' field.

[Verwijderd]

Denk dat 100 mensen 100 verschillende meningen hierover hebben. Hier de mijne.

Als ik met database werk dat zie ik deze al een los staand iets waarin de data wordt opgeslagen. Ik wil dan dat de data zo ruw mogelijk de database in gaat. Met uitzondering van wachtwoorden, altijd gehashed. De database is hierdoor onder andere ook voor andere applicaties makkelijk en snel te gebruiken.

Stel jij wilt die database voor een webformsapplicatie gebruiken, moet je daarin weer rekening gaan houden dat alles html encoded is.

Maw.

Database bevat ruwe gegevens.
Business logic handelt alle logica af (berekeningen, algortimes), je gebruikt .NET dus kun je daar mooi klasse's van maken en DLL's mee bakken (kun je weer voor je windows form app gebruiken)
Een je webapp moet die dingen doen die specifieke voor je webapp zijn..... dus de data valideren/veranderen.
Omdat je .NET gebruikt: User Controls alle weergave van data en elementen

[gorgi_19]

In het kader van alle meningen gelden..

Zelf ben ik oa ook bezig met CMS-en; voor opslaan heb ik de methodiek van EfBe gebruikt. Dus: een kolom met de 'ruwe pagina' en 1 pagina welke al volledig HTML opgemaakt is.

De redenen voor deze keuze zijn geweest:
1. Snelheid: Doordat de ruwe code niet steeds door mijn parser heen moest worden gehaald, scheelde dit rond de 30% - 40% in snelheid
2. Compatibiliteit. Mocht er later een nieuwe parser gebruikt worden of een ander CMS, dan kan dit relatief eenvoudig gedaan worden, omdat alle ruwe code nog beschikbaar is.

[mOrPhie]

Verwijderd schreef op 03 januari 2003 @ 06:03:
Denk dat 100 mensen 100 verschillende meningen hierover hebben. Hier de mijne.

Als ik met database werk dat zie ik deze al een los staand iets waarin de data wordt opgeslagen. Ik wil dan dat de data zo ruw mogelijk de database in gaat. Met uitzondering van wachtwoorden, altijd gehashed. De database is hierdoor onder andere ook voor andere applicaties makkelijk en snel te gebruiken.

Stel jij wilt die database voor een webformsapplicatie gebruiken, moet je daarin weer rekening gaan houden dat alles html encoded is.

Maw.

Database bevat ruwe gegevens.
Business logic handelt alle logica af (berekeningen, algortimes), je gebruikt .NET dus kun je daar mooi klasse's van maken en DLL's mee bakken (kun je weer voor je windows form app gebruiken)
Een je webapp moet die dingen doen die specifieke voor je webapp zijn..... dus de data valideren/veranderen.
Omdat je .NET gebruikt: User Controls alle weergave van data en elementen

Zoals ik in mijn beginpost al aangaf denk ik ook dat dat de beste mogelijkheid is. Ik wil alleen nog even testen hoe het responsegedrag zal zijn indien er meerdere user tegelijk op het systeem zitten. Verder ben ik ook compleet voor het opslaan van raw data, ook voor het platform onafhankelijk zijn...

gorgi_19 schreef op 03 januari 2003 @ 08:20:
In het kader van alle meningen gelden..

Zelf ben ik oa ook bezig met CMS-en; voor opslaan heb ik de methodiek van EfBe gebruikt. Dus: een kolom met de 'ruwe pagina' en 1 pagina welke al volledig HTML opgemaakt is.

De redenen voor deze keuze zijn geweest:
1. Snelheid: Doordat de ruwe code niet steeds door mijn parser heen moest worden gehaald, scheelde dit rond de 30% - 40% in snelheid
2. Compatibiliteit. Mocht er later een nieuwe parser gebruikt worden of een ander CMS, dan kan dit relatief eenvoudig gedaan worden, omdat alle ruwe code nog beschikbaar is.

Dit zal op zich goed werken, echter als je met veel data te maken hebt, zal je niet blij worden van een dubbele opslag. Bovendien zit je met raw data altijd altijd goed, afgezien van de snelheid, maar zoals ik al zei, dat moet ik nog even utizoeken

iig, allemaal tnx voor de mooie reacties, die hier met wat mensen ook al een leuke dicussie te gevolg had

[EfBe]

Wat is 'veel' data? 100MB? 1GB?