Zu groß für Strato. Wachstum gefährlich.

Beitrag von **Mork vom Ork** » 28.01.2010, 22:06

net(t)worker hat geschrieben:auch gehören wichtige Projekte auf einem eigenem Server, und nicht irgendwo in ein shared hosting....

Na, was geht wohl eher in die Binsen? Ein eigener Server, mit dem man sich bestenfalls oberflächlich auskennt oder normales Hosting auf mehreren Maschinen bei einem Anbieter, der weiß, was er tut (der einem alle Serversorgen abnimmt und insbesondere keinen Kunden abklemmt, ohne Bescheid zu sagen)?

von **Anzeige von ABAKUS** »

SEO Consulting bei ABAKUS Internet Marketing
Erfahrung seit 2002

persönliche Betreuung
individuelle Beratung
kompetente Umsetzung

Jetzt anfragen: 0511 / 300325-0.

Beitrag von **Anonymous** » 28.01.2010, 22:23

na, dann erläutere uns doch mal schnell die Unterschiede zwischen einem Webspace und einem Managed Server aus Sicht das Users...

wer mit nem managed Server nicht klarkommt, kommt auch mit nem Webspace nicht klar....

Beitrag von **euroexchange.de** » 28.01.2010, 22:42

Also, ich muß mir das nochmal klarmachen.

Derzeit habe ich eine Datenbank mit einer Tabelle wie folgt:

ID| SUCHBEGRIFF| SYNONYME| ANLAGEDATUM| HITS

Mit z.B. den Datensätzen:

1| Schuhe| schöne Schuhe, Schuhleder, Schuhformen, Mode, Kleidung
2| Der Schuh| Film, Bully, Indianer, Bekleidung, Beinkleid, Komödie
3| Schuhe kaufen| Deichmann, Geld, Frauen, Kleidung, Sucht

u.s.w.

Jetzt müßte ich diese Tabelle zerlegen in ZWEI Tabellen:

Tabelle 1.
ID| SUCHBEGRIFF| ANLAGEDATUM| HITS

Tabelle 2.
ID| SYNONYME

verbunden über einen eindeutigen Schlüssel in einem zusätzlichen Feld, wobei in den Tabellen die Spalten Suchbegriff und Synonyme einen Index verpaßt bekämen.

Der Vorteil wäre dann, das bei einer Abfrage (Query) nicht soviele Daten durchsucht werden müßten?

Verstehe ich das richtig?

Sorry networker:
Ich habe mich mit der Volltextsuche noch nicht beschäftigen können. Mache ich aber auf jeden Fall auch noch.

Beitrag von **Lord Lommel** » 29.01.2010, 00:30

ID| SUCHBEGRIFF | ANLAGEDATUM| HITS
ID| SYNONYME | SUCHBEGRIFFID

Also pro Synonym einen Datensatz. An jedem Suchbegriff hängen dann mehrere Synonyme dran.

Wenn bei dir aber alle Synonyme auch Suchbegriffe sind, dann:

ID| SUCHBEGRIFF | ANLAGEDATUM| HITS
SUCHBEGRIFFID1 | SUCHBEGRIFFID2

Damit baust du dann Verbindungen zwischen den Suchbegriffen.

Das kann man zwar dann alles noch optimieren, aber so bist du erstmal das LIKE los und das bringt dir schon ne Menge.

Beitrag von **euroexchange.de** » 29.01.2010, 00:56

@Lord Lommel.

Vielen Dank für Deine Erklärung.

Wenn ich jetzt aber alle Synonyme angezeigt haben möchte in denen der Begriff "Schuh" vorkommt, egal was davor bzw. dahinter steht, muß ich dann nicht doch wieder mit %LIKE% abfragen?

Beitrag von **Kassandra70** » 29.01.2010, 02:46

Es wäre natürlich einfacher dir zu helfen, wenn man etwas genauer wüsste, was du mit den Daten anstellst

Der google-cache läßt aber einige Quälerei für die DB erkennen.

Wir sollten mal wegkommen von dem blöden Synonym. Denn Komödie ist kein Synonym von Der Schuh. Der Schuh (des Manitu? nehme ich an) ist sicherlich eine Komödie, Schuhe einkaufen kann eine Komödie sein, ist aber meist ein Drama (jedenfalls bei mir).

Nennen wir es mal, du willst einen Eintrag in der DB (Datenbank) mit passenden TAGS versehen, so wie in einem Blog einen Artikel.

Du hast also einen Artikel in der DBArtikel
ID 1
Name Schuhe
Angelegt am ....
Aufgerufen 3765x
ID 2
Schuhe kaufen
....
....

Und jetzt überlegst du dir wozu [zu welchen Tags] der Artikel jeweils gefunden werden soll:
Datensatz 1: Damenschuh, rote Schuhe, Schuhleder
Datensatz 2: einkaufen, Deichmann, Damenschuh

und hast dann eine weitere DBTags
ID Name
1 Damenschuh
2 rote Schuhe
3 Schuhleder
4 einkaufen
5 Deichmann
Damenschuh war ja schon drin.

Und nu verknüpfst du das noch die DBArtikel mit der DBTags
IdArtikel IdTag
1 1
1 2
1 3
2 4
2 5
2 1

suchst du nach Damenschuh (IdTag=1) wird dir Artikel 1 und 2 als Ergebnis ausgeliefert.

Willst du, dass Artikel 1 auch zu Schuhe gefunden wird, dann musst du den Artikel auch mit dem entsprechenden Tag versehen. In der DB Tags hättest du also einen Eintrag 6 Schuhe und in der DB Tags zu Artikel den Eintrag 1 (die Artikel Id) 6 (die Tag Id) … Soll auch Artikel 2 zu Schuhe gefunden werden, dann muss es natürlich auch 2 – 6 geben.

Wichtig ist halt, dass jeder Tag ein eigener DB Eintrag ist. Und das schöne ist, in der DB, die die Artikel und die Tags miteinander verknüpft, kann man gar nicht mit % suchen

Jedenfalls nicht erfolgreich.

Wichtig: Ob das wirklich die beste Lösung für dich ist, kann man gar nicht so genau sagen, denn dafür müsste man doch ein wenig mehr von deiner Datenbankstruktur kennen, wie du die Daten nach welchen Kriterien ausgespuckt haben möchtest und eigentlich auch, wie die Daten in die Datenbank kommen sollen.

Aber was nicht geht, bzw. keine Lösung ist, ist:

euroexchange.de hat geschrieben:Jetzt müßte ich diese Tabelle zerlegen in ZWEI Tabellen:

Wenn du dann einfach nur ID SynonymE in die zweite Tabelle haust, hast du ja immer noch das Feld, das du eigentlich nur mit %schuh% durchsuchen kannst.

Aber das alles hilft dir ja bis zum 4.2. nicht wirklich weiter, bis dahin, dass du das Problem sicherlich auch gerne vorher lösen würdest. … du solltest also das Skript wie Strato schreibt inaktiv machen – zumindest die Abfragen mit den LIKE %schuh% Abfragen, dir die DB frei schalten lassen und dir die Daten da erst einmal als Sicherung ziehen.

Beitrag von **profo** » 29.01.2010, 04:04

@Euro, bevor Du jetzt irgendwelchen komplizierten Sachen versuchst, komme ich noch mal auf Mork zurück. Der einfachste Weg aus dem Schlamassel ist ein Index oder ein Fulltext Index. Also falls Du auf der Spalte "Synonyme" noch keinen Index hast ("show index from deine_tabelle where column_name like 'synonym';" oder einfach "show create table deine_tabelle"), dann

1. solltest Du einen Index anlegen ("alter table deine_tabelle add index (`synonyme`);"). Dein "like %bla%" sollte dadurch *viel* resourcenschonender sein.

2. Alternativ könntest Du statt des normalen Indexes einen Full Text Index einrichten ("alter table deine_tabelle add fulltext index (`synonyme`); "). Die Abfrage nach dem Vorhandensein zweier Suchbegriffe ginge dann a la: "select id from deine_tabelle where match(synonyme) against ('+Suchbegriff1 +Suchbegriff2' in boolean mode);".

Was jetzt resourcenschonder ist kann ich aber nicht wirklich sagen, vermutlich 1.

Viel Erfolg!

Beitrag von **Margin** » 29.01.2010, 08:31

Wir waren somit gezwungen Ihre Datenbank kurzfristig abzuschalten und bitten hierfür um Ihr Verständnis. (Grundlage ist § 4.3 / Abschnitt I der von Ihnen anerkannten AGB der STRATO AG)

Man höre und staune.
Soviel Glück hatten wir nicht, wir haben einfach wie die Bekloppten Fehler gesucht, da angeblich alles in Ordnung war.

Beitrag von **catcat** » 29.01.2010, 09:03

net(t)worker hat geschrieben:na, dann erläutere uns doch mal schnell die Unterschiede zwischen einem Webspace und einem Managed Server aus Sicht das Users...

wer mit nem managed Server nicht klarkommt, kommt auch mit nem Webspace nicht klar....

Naja. Bei nem Webspace haste halt Dein php-Admin und noch z.B. Confixx. Die paar bunten Bildchen sind noch überschaubar

Aber bei nem Managed Server haste cPanel, möglicherweise noch nen WHM Manager, und ganz viele bunte Bildchen, hinter denen sich noch mehr bunte Bildchen verstecken. Und Du kannst wesentlich mehr kaputtklicken!

Beitrag von **DanielS** » 29.01.2010, 09:30

catcat hat geschrieben:Naja. Bei nem Webspace haste halt Dein php-Admin und noch z.B. Confixx. Die paar bunten Bildchen sind noch überschaubar

Aber bei nem Managed Server haste cPanel, möglicherweise noch nen WHM Manager, und ganz viele bunte Bildchen, hinter denen sich noch mehr bunte Bildchen verstecken. Und Du kannst wesentlich mehr kaputtklicken!

Kommt auf den Managed Server an. Bei all-inkl hast Du kaum einen Unterschied, außer vielleicht dass Du ein Monitoring dazu kriegst.

Beitrag von **webpilot** » 29.01.2010, 09:59

DanielS hat geschrieben:
catcat hat geschrieben:Naja. Bei nem Webspace haste halt Dein php-Admin und noch z.B. Confixx. Die paar bunten Bildchen sind noch überschaubar

Aber bei nem Managed Server haste cPanel, möglicherweise noch nen WHM Manager, und ganz viele bunte Bildchen, hinter denen sich noch mehr bunte Bildchen verstecken. Und Du kannst wesentlich mehr kaputtklicken!
Kommt auf den Managed Server an. Bei all-inkl hast Du kaum einen Unterschied, außer vielleicht dass Du ein Monitoring dazu kriegst.

Kann ich bestätigen. Die Managed Server bei all-inkl.com sind absolut easy zu administrieren. Von der Seite her gibt es keinen unterschied zur Administration eines Webspaces. Ich bin seit Jahren bei der Firma und absolut glücklich. Günstiger geht es bestimmt noch, doch der Support ist einfach weltklasse und das zählt für mich.

Beitrag von **Mork vom Ork** » 29.01.2010, 11:04

DanielS hat geschrieben:
catcat hat geschrieben:Naja. Bei nem Webspace haste halt Dein php-Admin und noch z.B. Confixx. Die paar bunten Bildchen sind noch überschaubar :)

Aber bei nem Managed Server haste cPanel, möglicherweise noch nen WHM Manager, und ganz viele bunte Bildchen, hinter denen sich noch mehr bunte Bildchen verstecken. Und Du kannst wesentlich mehr kaputtklicken!
Kommt auf den Managed Server an. Bei all-inkl hast Du kaum einen Unterschied, außer vielleicht dass Du ein Monitoring dazu kriegst.

Wozu brauche ich dann so einen Managed Server, wenn sowieso kein Unterschied zum Webhosting besteht? Weil ich mich dann nicht um meine kaputten Skripte kümmern muss und es c00l ist, bei den Schulkameraden mit einem „eigenen Server“ angeben zu können? Bockmist.

Beitrag von **DanielS** » 29.01.2010, 11:09

Mork vom Ork hat geschrieben:Wozu brauche ich dann so einen Managed Server, wenn sowieso kein Unterschied zum Webhosting besteht? Weil ich mich dann nicht um meine kaputten Skripte kümmern muss und es c00l ist, bei den Schulkameraden mit einem „eigenen Server“ angeben zu können? Bockmist.

Weil Du Dich dann alleine auf einer Server austoben kannst und sicher bist, dass nicht andere Projekte drauf laufen (die evtl. durch eine schlechte DB-Struktur den Server lahmlegen können).

Ach ja, in Deinem letzten Satz fehlt ein Verb.

Beitrag von **webpilot** » 29.01.2010, 11:12

@ Mork

Wegen der Leistung, man nicht alle Scripte auf Webhosting-Paket installieren kann/darf und man evtl. spezielle Server-Einstellungen benötigt.

Beitrag von **SloMo** » 29.01.2010, 11:21

Und wegen der Eigenverantwortung. Wenn der Server lahmt, sind nur die eigenen Sites betroffen und es gibt für den Hoster keinen Grund, irgend etwas abzuschalten. Außerdem ist man vor den Fehlern anderer Nutzer desselben Servers geschützt.