Re: jsp vs php - Grupy dyskusyjne w eGospodarka.pl

eGospodarka.pl › Grupy › pl.comp.programming › jsp vs php › Re: jsp vs php

X-Received: by 10.49.104.209 with SMTP id gg17mr1910093qeb.7.1368439555442; Mon, 13
May 2013 03:05:55 -0700 (PDT)
X-Received: by 10.49.104.209 with SMTP id gg17mr1910093qeb.7.1368439555442; Mon, 13
May 2013 03:05:55 -0700 (PDT)
Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!newsfeed2.atman.pl!newsfeed.
atman.pl!goblin2!goblin.stu.neva.ru!feeder1.cambriumusenet.nl!82.197.223.103.MI
SMATCH!feeder3.cambriumusenet.nl!feed.tweaknews.nl!209.197.12.242.MISMATCH!nx01
.iad01.newshosting.com!newshosting.com!news-out.readnews.com!transit3.readnews.
com!209.85.216.88.MISMATCH!m7no5275233qam.0!news-out.google.com!y6ni29564qax.0!
nntp.google.com!m7no5275231qam.0!postnews.google.com!glegroupsg2000goo.googlegr
oups.com!not-for-mail
Newsgroups: pl.comp.programming
Date: Mon, 13 May 2013 03:05:55 -0700 (PDT)
In-Reply-To: <kmq6hd$rac$1@speranza.aioe.org>
Complaints-To: g...@g...com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=178.36.216.67;
posting-account=xjvq9QoAAAATMPC2X3btlHd_LkaJo_rj
NNTP-Posting-Host: 178.36.216.67
References: <c...@g...com>
<klqg29$o16$1@news.mm.pl>
<0...@g...com>
<klsle1$ogf$1@news.mm.pl>
<2...@g...com>
<km4nal$kkp$1@news.mm.pl>
<4...@g...com>
<d...@g...com>
<e...@g...com>
<51874eb2$0$1250$65785112@news.neostrada.pl>
<6...@g...com>
<kmau09$ju5$1@speranza.aioe.org>
<8...@g...com>
<kmbgce$ile$1@speranza.aioe.org>
<e...@g...com>
<kmd4e5$k0a$1@speranza.aioe.org>
<3...@g...com>
<kmijq0$tc$1@speranza.aioe.org>
<2...@g...com>
<kmq6hd$rac$1@speranza.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <6...@g...com>
Subject: Re: jsp vs php
From: "M.M." <m...@g...com>
Injection-Date: Mon, 13 May 2013 10:05:55 +0000
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
Xref: news-archive.icm.edu.pl pl.comp.programming:203348
[ ukryj nagłówki ]
W dniu poniedziałek, 13 maja 2013 09:59:47 UTC+2 użytkownik Michal Kleczek napisał:

> W calym watku to sie pojawia wielokrotnie:
> 1. twoje rozwiazania tego nie zapewniaja bo operuja na poziomie systemu
> plikow - a od systemu plikow do fizycznego rozlozenia danych na
> nosnikach jeszcze baaaaaaardzo daleka droga
Czy potrafisz to jakos uzasadnic?

> 2. DBMS jest dokladnie pod to projektowany, by minimalizowac ilosc
> operacji we/wy przy dostepie do danych
Tu na pewno mylisz sie. Pisalem w tym watku kilka razy, napisze jeszcze raz:
projektowany jest po pierwsze pod ogolny przypadek. Poza tym projektowany
jest pod wygode, elastycznosc, bezpieczenstwo, transakcje, wielodostepnosc
itd. Minimalizowanie operacji we/wy ma ktorys z kolei priorytet.

> Wziac dobry (odpowiedni do zastosowan) DBMS. NIE probowac robic "lepiej".
Nie mam bladego jak uzywasz slowa "lepiej", pewnie zupelnie inaczej niz ja.

> Kazdy indeks jest po to, zeby minimalizowac czas dostepu do danych.
> Rozne rodzaje indeksow sa przeznaczone do
> a) roznego rodzaju dostepu
> b) roznych rodzajow danych
> Sa rozne rodzaje indeksow. Na poczatek:
> http://en.wikipedia.org/wiki/Database_index
A jesli dane sa rozrzucone po dysku, to zaden indeks nie pomoze i
trzeba zrobic tyle odczytow, ile jest danych, prawda?

> Trzymanie danych "obok siebie" niekoniecznie jest najlepsza strategia.
Dobrze rozumiem: Niekoniecznie, czyli może być najlepszą?

> > Clustered mozna
> > zakladac tylko na jedno pole, wiec odpada, prawda?
> Nieprawda.
Czytalem ze tylko na jedno, no ale dobra. Wiec pytanie: jak w bazach
jest realizowany clustered na więcej niż jednym polu?

> Jestem - probuje ci chyba bezskutecznie uswiadomic, ze proponowane przez
> ciebie rozwiazania to nic innego jak indeksy w DBMS.
Moze sie mylisz? Moje rozwiazanie w jednym programie potrzebuje kilku
sekund a na sqlite trwalo 90 minut na nieplnej bazie.

> Prawie na pewno szybciej, niz zrobi to kod pisany przez ciebie.
Tez to pisalem wiele razy. Nie chodzi o sciganie sie z baza danych
na poziomie samego kodu. Chodzi jeszcze o sciganie sie na poziomie
stuktur danych.

Pozdrawiam