PHP уеб платформи

[tedy]

значи имам вавеждане от потребителя на a\a\\aa\\\aaa\\\\aaaa

то се ескеипва на a\\a\\\\aa\\\\\\aaa\\\\\\\\aaaa

и се въвежда в sql

Не точно.

Имахме предвид, че то не 'се ескейпва на a\\a\\\\aa\\\\\\aaa\\\\\\\\aaaa',

а ти още на входа на скрипта имаш вече ескейпнат стринга до това. От автоматичния addslashes().

Един прост дебъгинг да изведеш стойността на $_POST['text'], и след ескейпа, щеше да ти покаже къде какъв стринг получаваш.

След mysql_real_escape_string() ти получаваш ' a\\\\a\\\\\\\\aa\\\\\\\\\\\\aaa\\\\\\\\\\\\\\\\aaaa' .

Бъркани яйца...

Просто правиш stripslashes() на $_POST[...] ако get_magic_quotes_gpc() върне Труе, и след това мааш по въпроса. И именно това можеш да си го вкараш в поне функция, за да не те тормози занапред.

Като изкараш данните от mysql, ползваш само htmlspecialchars().

[po_taka]

не си разбрал правилно, ти правиш strip_slashes на изхода от mysql, а не трябва

Като изкараш данните от mysql, ползваш само htmlspecialchars().

ето това ми е проблема явно.10х

 

а иначе магическите кавички са ми изключени, нз дали навсякъде става но при мен слагам фаилове php.ini в директориите с php файлове , и в него пиша magic_quotes_gpc = Off и се изключват.

[tedy]

ето това ми е проблема явно.10х

 

а иначе магическите кавички са ми изключени, нз дали навсякъде става но при мен слагам фаилове php.ini в директориите с php файлове , и в него пиша magic_quotes_gpc = Off и се изключват.

Еми то ти всъщност защото се изрази някак "се губят някои \", но кои точно и колко точно не стана ясно. В повечето такива случаи грешката е именно в магическите куотес, особено ако човек не ги знае че ги има.

Тук може би това което трябва да се спомене при по-начинаещи програмисти объркващото е кога се ексейпва и кога се ънескейпва (като с stripslashes).

Ескейпва се когато се задава literally стринг в кода, или когато се подготвя стринг, който се подава на друга система (като SQL заявка). Понеже парсера използва чертата като ескейп символ.

Реалните данни, които влизат в системата (в базата или в променливата в кода) са без чертите.

Т.е. в случая ти в базата имаш правилния стринг, но на излизане оттам му отнемаш черти.

 

Това, че ти си си настроил magic_quotes Off, не значи че ако качиш скрипта някуъде, ще е така. И това не е само за magic quotes. Всичко, което може да се настройва в php.ini или при компилирането на пхп, го проверяваш как е текущата настройка, иначе това което пишеш, ще върви Само при теб

 

Да споделя, че на текущата ми инсталация $_SERVER['REMOTE_ADDR'] връща ::1 (т.е. IPv6 локалхост) . Явно е от hosts-а, така че ако човек провери за 127.0.0.1, познай

 

Също така наскоро видях, че на един определен хостинг автоматичното (implicit) преобразуване на float към стринг резултира в експонентен формат 3.5667E+13 , докато на всички останали си беше пълното 3476873784785 или както е. Това дънеше цял един клас . Та за обица на ухото.

[ShitHappen]

Имам да задам в темата един ( може би ) глупав въпрос ,но все пак искам да попитам тук , не да гледам някакви кофти написани скриптове. Как става номера с това да имаш някаква картинка за даден продукт и като влезнеш при по-детайлното му описание да излизат и другите картинки свързани в нещо като мини-галерия ?

 

Пример : http://www.newegg.com/Product/Product.aspx...-026-_-Homepage

 

Картинките като blob ли трябва да се пазят за да има връзка между тях ,чрез таблици и id-та или да се качват по някакъв начин директно в определени папки. Имам една идея , но може би не е добра : При всяко качване на картинка за даден продукт ,ако е първа в файловите директории се създава нова папка с неговото име ( на продукта ) примерно "images/имеНаПродукт/" , ако не е първа се добавя просто в папката . Когато трябва да се покажат картинките се обхожда цялата папка и се показват само файловете които са само с разрешени разширения. Има голям проблем тук : при всяко ново качване се прави нова папка , което си е доста тежко като задача към сървъра , а и обхождането на целите папки си е трудоемка задача , какво ще стане ,ако в тях се сложат и pdf файлове и някакви други данни ? В общи линии развих малко идеята по време на писане , сигурно после ще ми дойде още нещо на ум ,но смятам ,че ако се съберат нещата в таблици ще стане далеч "по-изискано" , очаквам мнения , подкрепени и с малки дози код , за да схвана идеята .

Поздрави.

[tedy]

...

В зависимост от приложението.

Не се притеснявай за многото папки, ако се разровиш в тази секция, преди година питах подобен въпрос за линукс сървър, понеже всеки потребител щеше да има по няколко снимки, и се питах и аз как да организирам нещата (ставаше дума обаче за потенциален брой потребители 100,000 като в действителност са около 70,000, но растат).

Та се оказа, че не е проблем. 70-тина хиляди директории, всичките на едно ниво, и проблем с тях няма .

 

Ако за теб не е проблем да управляваш снимките така, без записи в базата, и да ги взимаш директно от директорията, не виждам проблем. За мен би бил по-голям проблем директориите да ги именувам с имената на продуктите. Не обичам имена на кирилица, и да се грижа освен това да заменям разни невалидни символи с други, защото името на продукта може да е всякакво, вкл. и 100-200 символа.

Ако тия продукти ги пазиш в таблица, примерно products, по-добре за име на директория да вземеш unique key-поле на тая таблица, най-добре primary key, което е auto_increment.

 

Аз лично за всеки юзър пазя и снимките в базата, но имената им са числа, и самите файлове ги именувам спрямо primary key полето в таблицата със снимките, и след това записвам файла в съответната директория със съответното име-key. Така поне не пазя в поле име на файла.

Пазя ги в базата, понеже към всяка снимка имам и други данни, както и поредност, в която се показват в сайта, т.е. order поле, започващо от 1.

 

Та зависи дали искаш да пазиш и други данни към снимките. Ако не, може и без отделна таблица за тях. Дори ако са малко продуктите, и общо снимките няма да са примерно 50 - 100 хиляди, може всички в една директория да ги ръгнеш за по-лесно управление . И да ги именуваш с нещо като 123_2.jpg, като 123 е ИД-то на продукта, а 2 е поредната снимка за продукта .

 

Просто идеи.

[djadomraz]

"images/имеНаПродукт/"

 

Теди добре ти обясни, аз само да допълня, че преди 3-4 дена един приятел ми сподели че за съжаление не ме бил послушал относно това къде да пази картинките (помня че преди след доста спорове стигнахме до извода че в базата да се пазят е по-кофти идея - няма кеширане, тормозиш излишно сървъра с несвойствени за него неща) и сега той съжалява защото се оказало че базата данни е лимитирана до 300мб докато дисковото пространство на сървъра до 4гб.

 

Също така относно "имеНаПродукт" - НИКОГА АМА НИКОГА недей да ползваш за системна идентификация нещо, което потребителя си е въвел. Примерно много пъти съм се сблъсквал с побен дизайн таблица OrderItems и вътре вместо ProductID има ProductName. И после като промени някой името на продукта, което дори и да е уникално и кратко, както примерно са обозначенията на гуми - 192х60х13 - примерно сложи по 1 интервал между хиксовете за четливост и след това се появяват проблеми... или пък точно по тази причина не може да се промени, а ако е бил достатъчно умен програмиста - пипнеш името и чакаш 15 минути да се промени навсякъде по OrderItems заради cascading update-a.

 

Слагай си по 1 поле за уникален ключ на всяка таблица и по него идентифицирай записите - така ще имаш малко излишни данни и много ама МНОГО по-малко проблеми.

 

И друго - защо към всяка картинка не сложиш и коментар или нещо такова - така няма да има нужда да минаваш по директорията (не че е голяма философия де) и да търсиш файлове а направо ще е ясно кое какво е.

[ShitHappen]

И друго - защо към всяка картинка не сложиш и коментар или нещо такова - така няма да има нужда да минаваш по директорията (не че е голяма философия де) и да търсиш файлове а направо ще е ясно кое какво е.

Мда , това за име на продукт е доста глупаво , по-скоро по някакво id ще е далеч по-добре . Мерси djadomraz.

Може ли да ми разясниш това което съм quote-нал какво означа всъщност , да сложа коментар към всяка картинка ?

[djadomraz]

Мда , това за име на продукт е доста глупаво , по-скоро по някакво id ще е далеч по-добре . Мерси djadomraz.

Може ли да ми разясниш това което съм quote-нал какво означа всъщност , да сложа коментар към всяка картинка ?

 

Ами имаш снимки - примерно на дрехи - на едната хората могат да напишат "лице", на другата "гръб" на третата примерно да е "материал" и да е сниман от много близо плата - такива работи. Т.е. по няколко думи описание така че под малката картинка да имаш и пояснителен текст нещо, евентуално малко по-дълъг текст с пояснения към по-голямата картинка - пък като няма - няма, където има показваш, където няма очевидно не показваш нищо. Така хем знаеш кои са имената на файловете защото всеки от тези записи (т.е. поясненията) ще си има уникално ID, хем може да имаш и нещо полезно като текст.

 

Аз бих сложил даже още 1 текстово поле за вътрешни бележки - такива които да се виждат само в административната част.

[tedy]

Е, ся подробности..

И тогава може да се мине без таблица, а към всеки файл да има и един текстов .txt със същото име и в него да са описанията, а \r\n\r\n да е разделител между големи и малки описания.

 

Шегувам се разбира се.

Ако няма описания, и без базата става, то нали това беше и проблема..

[djadomraz]

Аз само разсъждавам на глас. Толкова ако не трябват описания - по една директория за всеки продукт и картинките сложени вътре. Но определено е добра идея да има таблица с описания коя картинка каква е, евентуално нещо тип на картинката и дали да се показва на "широката публика" или да е скрита и само за вътрешна употреба и т.н. Отделно ако се мине през таблица може всичките картинки да са в една единствена директория (не съм сигурен че е много добра идея всъщност, аз даже бих ги разделил по директории за продукт а отделно всички по групи продукти и т.н.

 

Колкото по-разделени толкова по-добре. Не за друго ами някой ден ще се наложи да бърникам нещо с FTP или подобно през бавна връзка и тръгне ли да се list-ва подобна директория почвам жестоко да съжалявам че изобщо съм опитал и хайде наново логване, едно друго...

[lil_stenly]

Еми така се прави , ламерската , всичко в една директория , защото да си хабиш времета като разделяш картинките за всичко е много загубено време ... (това е някаква българска логика) времето е пари .

Аз тука имам в нас оракъл , но е версия 2 и все пак е оригинал .

Изобщо не мога да се разбера с него .

п.п. Дайте четиво на нашенски език по този въпрос , да прочета нещо повеече .

[djadomraz]

Аз тука имам в нас оракъл , но е версия 2 и все пак е оригинал .

Изобщо не мога да се разбера с него .

п.п. Дайте четиво на нашенски език по този въпрос , да прочета нещо повеече .

 

Oracle 2 ??? Ти сериозно ли ? Вече има 11g ти с тая 2ка изби рибата...

 

Четиво на нашенски по-добре не. Аз досега една свястно преведена книга която при това да има и някаква поне малко по-ценна информация от лекциите ми в университета не съм видял.

 

Мога ли все пак да разбера какво се опитваш да постигнеш с този оракъл и ЗАЩО точно с него - нещо ме загриза любопитството...

[lil_stenly]

Просто споменах какво изнамерих в нас от старите неща .

Заинтересува ме оракъл като цяло .

Работил съм с мъсял и просто съм любопитен ... хттп , фтп или всякакви други сървъри ме влечат .

п.п. Просто нямам време да седна за да се самообразовам в момента и като се има на предвид чуждия език се натрупва и превод за да науча нещо в повече .

[djadomraz]

Просто споменах какво изнамерих в нас от старите неща .

Заинтересува ме оракъл като цяло .

Работил съм с мъсял и просто съм любопитен ... хттп , фтп или всякакви други сървъри ме влечат .

п.п. Просто нямам време да седна за да се самообразовам в момента и като се има на предвид чуждия език се натрупва и превод за да науча нещо в повече .

 

Без да знаеш поне на някакво ниво английски колкото да четеш документация си буквално обречен.

 

А колкото до "ей така да се побъзикам с oracle" просто не става. Доста сериозно нещо е и за да го ползваш първо трябва сериозна причина (като примерно - имаме 2 терабайта база данни, определено ни трябва oracle, ако ще и лиценза да е по $40,000/CPU в сървъра) и след това сериозен администратор който да го настрои... Ти колко седмици си готов да четеш документация за да го подкараш. Последно мои приятели работеха в панаира - документацията на 7ма версия на оракъл се побираше в 3 или 4 кашона около метър на метър на 50см

[lil_stenly]

Човек не интерпретирай казаното от мен .

Не искам само да се бъзикам с оракъл , а да науча нещо повече за програмата .

Целта ме не е управляване на огромна база данни ... просто искам да знам повече за тези неща .

п.п. Знам чужди езици и щом на нашенски е лош превода ще се мине на тях тогава .

[ShitHappen]

Еми така се прави , ламерската , всичко в една директория , защото да си хабиш времета като разделяш картинките за всичко е много загубено време ... (това е някаква българска логика) времето е пари .

Аз тука имам в нас оракъл , но е версия 2 и все пак е оригинал .

Изобщо не мога да се разбера с него .

п.п. Дайте четиво на нашенски език по този въпрос , да прочета нещо повеече .

Ей , ама си заслужаваш мястото в бисерите на форума , май алкохола е дошъл в повече снощи , няма нищо , на всеки се случва Хубаво пак ,че не си стигнал до екзестенциалният въпрос : "Е ли моя Oracle оригинал или не е ? " . Aма това с българската логика ме разби , просто ми направи деня ( днес ) далеч по-хубав , мерси много

[djadomraz]

Човек не интерпретирай казаното от мен .

Не искам само да се бъзикам с оракъл , а да науча нещо повече за програмата .

Целта ме не е управляване на огромна база данни ... просто искам да знам повече за тези неща .

п.п. Знам чужди езици и щом на нашенски е лош превода ще се мине на тях тогава .

 

Не се разбрахме нещо май... каква изненада

 

Това което имах предвид е, че Oracle е доста сериозна база данни. Горе-долу каквото е Cisco при рутерите. Можеш спокойно да си вземеш някакъв netgear или linksys и да си поиграеш малко с него и да направиш някакви неща. Докато за да подкараш едно Cisco без преди това да си пипал никога подобни ще ти трябва може би месец. Е същото е с Oracle.

 

Но няма лошо, щом си ентусиаст - действай. Въпреки че така без никаква цел просто от любов към спорта не мисля че ще направиш кой знае какво... по-добре си постави някаква задача и се опитай да я решиш...

[ShitHappen]

Имам нужда от малко assistance

Имам 3 таблици posts,users и една която смятам да събира всичко което се налага joiner .

Направих и 2 метода за добавяне на нов пост като същевременно искам да запазя и кой юзър го е добавил. В момента просто не се сещам как да убединя двете query-та .

 

		public function add($params)
	{
		$sql = "INSERT INTO posts(title,description,created) VALUES (:title,:description,:created) ";
		$executer = $this->query($sql);
		$executer->execute(array(":title" => $params['title'],":description" => $params['description'],":created" => date("y/m/d : H:i:s", time()) ));
		$this->addAuthor($params);
		if($executer) 
		{
			return true;
		}
	}
	
	private function addAuthor($params)
	{
		$postsId = $this->counter(posts);
		$postsId = $postsId++;
		$sql = "INSERT INTO joiner(post_id,user_id) VALUES (:post,:user)";
		$executer = $this->query($sql);
		$executer->execute(array(":post" => $postsId , ":user" => $params['user']));			
	}

 

Малко помощ ще е нужна , както и всякакви коментари/критики

[mIRCata]

В Таблицата с постовете, сложи директно ключ към ID на потребителя, вместо да използваш тази трета таблица.

Освен ако постове може да са без потребител, или пък искаш да ти се водят няколко потребителя за едно мнение.

Иначе ако смяташ да знаеш всяко мнение от кой е(пък и най-логично да е така) забий ID на потребителя в таблицата с постовете

Понеже не съм много навътре в PHP,но от това което виждам взимаш ID като разчиташ, че всички мнения са ти на място(няма изтрити) и за следващи ID взимаш броя записи в таблицата.

Ако е така, , сложи си ID-то, или там както се казва първични ключ да е autoincrement и да ти се увеличава само. Обаче тук ми бяга идеята как да го вземеш и да го използваш в следващата таблица. Пак повтарям зле съм с PHP-то. На Firebird там си има генератори и предварително си заделям стойност за ключа на записа, но в MySQL нямам идея как се взима при autoincrement полетата.

 

Така както аз го разбирам, взимаш броя записи в таблицата, увеличаваш ги с 1 и това пишеш като POST_ID

Ако брояча е взел стойността преди INSERT-а може да е вярно, но ако го взимаш след, то в него ти е включено като бройка и текущо вкараното и ти увеличаваш с още 1 и би трябвало да сочи нейде си.

Но ако може да триеш представи си ситуацията. Имаш три записа - пишеш 4-ти. Броя става 4 и ти си добавяш връзка към 4. После триеш едно мнение. Записите стават 3, и ти пак слагаш ново - тук брояча пак ще ти даде 4, но новото мнение ще е със ID 5 и тогава онази таблица ще ти сочи нещо друго, дето няма да го има.

 

Обаче най-добре Дядо Мраз и Теди да дадат мнение. Че и на мен ми интересно как ще се подходи със взимането на ID-to. за записа в POSTS

[ShitHappen]

Мда , идеята точно тук да се ползва допълнителна таблица е някак си глупава . Но като цяло идеята да се ползва 3та таблица ще е добре застъпена ,ако ще трябва да направя категории (примерно) тогава един пост ще може да е в много категории както и една категория ще има много постове.

Да , сетих се за ID-то което вкарвам още когато го писах ,че може да изтрия някой пост и auto_increment-a да обърка нещата . Просто тествам и ме домърза да напиша един метод за взимане на последното добавено ID .

[mIRCata]

Ако си на MySQL 5 използване на stored procedurs няма ли да помогне по някакъв начин.

Това с категорийте добре - тогава ти трябва трета таблица - в нея казваш това мнение е за тази, тази и тази категория.

Но мнението е написано от един автор. Дори да е за 1000 категории, автора е 1.

[ShitHappen]

Ти май пак не разбра

Не говоря за автор вече , а само за пост и категория Въпроса ми беше : как да обединя двете query-та в едно ,че в момента не мога да се сетя , много далеч избягахме от темата .

Окей , това е отговор , мерси много

[mIRCata]

Не знам да има в SQL начин едновременно да вкарваш записи в 2 таблици.

[tedy]

Нещо ми се чини, че доста изкуствени проблеми и постове сте си създали и заплели

 

Идеята за свързваща таблица, за която говори ShitHappen, не е лишена от смисъл принципно, такава може да се ползва изкуствено за сързване когато няколко таблици използват някакво общо поле, като данните са разделени в различни таблици с цел по-добра поддръжка, ефективност, но и които не са задължително в 3-та нормална форма (ама как прозвуча само).

Една такава таблица в случая е излишна на пръв поглед, на втори също, но за нагледност може да е полезна.

Аз лично избягвам такива изпълнения.

С SQL принципно не съм чак толкова навътре (като Дядомраз примерно), не ми се случва да се налага да ползвам много сложни заявки.

 

В случая какво обединяване на заявките?! Таблицата очевидно е ненужна, и таблицата с постове си съдържа user_id поле, сочещо users. Щом като връзката е директна.

И никакво обединяване не се налага, освен при вземане на данните, най-много един join.

 

Имам малко странични въпроси към php кода.

Защо си разделил (принципно) двете заявки в двата метода (публичния и частния)? Понеже и двата метода са в един клас, каква е целта на това разделяне? Не е ли по-добре двете да бяха в един единствен публичен метод AddAuthor() ?! Даже не виждам защо се казва addAuthor, след като се добавя пост, а не автор.

 

Този клас ти ли си го писал, и query() метода в текущия клас ли е, или в наследен, защото ако е в наследен, той би трябвало да е абстрактна връзка към базата данни, ако не е, добре е работата с заявките да е в свой клас, дори може да направиш клас, с който изобщо да не се налага директно с SQL да се занимаваш. Така и по-лесно ще можеш да направиш драйвер за връзка с различни бази един ден.

[ShitHappen]

На въпросите , private метода се казва addAuthor ,защото добавя връзката към автора на поста Защо е отделен , в случая предполагам за четливост , определено има нужда от refactoring и за двата метода .

Класа аз съм го писал и той наследява друг клас който съдържа метода query , който просто try-ва да са подготви ( prepare() ) query-то и ,ако не стане хваща изключение . Смятам да създам доста подобни методи , тъй като във всеки дата обект се използват почти еднакви методи , за сега ползвам само интерфейс CRUD (add,update,delete,index) .

Колкото до различните бази и т.н. просто използвам PDO , просто за сега нямам достатъчно количество акъл в главата ,че да напиша добър клас който да използва различни видове ( драйвъри за ) за бази данни.

 

Подхода с 3те таблици найстина в описания по-горе случай не е приложима , но както дадох доста добър пример от практиката ( когато се правят категории ) тогава е почти задължителен ( да не кажа и напълно ).

 

Искам още един съвет , тъй като ще ми трябва малко композиция на класовете , представете си следното :

 

Имам клас Connector който ми прави връзката с db .

Класове които искат връзка с db ( съответно която се получава от Connector ) ,но същевременно да използват част от методи ( overriding ) в друг клас който примерно се казва CRUD . Как да ги композирам ? Очаквам мнения , дано е станало ясно .