Чекбокс и БД? Запис в едно поле...

S

sizif

Registered
Здравейте!

Налага се да правя записи в БД на променливи от чекбокс с повече от 20 възможности.
С извличането на стойностите и записа им по принцип се справям без проблем, но предвид броя им ми се иска да ги записвам само в 1 поле на таблицата в БД.

Дотук нищо смущаващо, но проблемът идва при редакцията - налага се вече избраните полета при попълването на формата да излизат с "чекет" (маркирани) във формата за редкация. Мъчното е, как да направя записите в едно поле на таблицата, така че да мога да го разделям, за да знам кои стойности са избрани и да ги маркирам във формата при редкация.

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

Интересува ме как да организирам записите от чекбокса, така че да са в едно поле, но да мога да ги чета поотделно? Има ли някаква готова функция за БД? И най-важното търсенето (сортирането) да бъде възможно при самата заявка към БД, а не отделно с експлоуд или друго?

Моля помогнете ми!

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

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

Ами релации? Връзка с някакви други данни няма ли да правиш?

Не знам за какво ще ползваш тези данни но аз бих ги сложил всяко в отделен ред от таблицата.
 
Здравей sizif
послушай Админа. Само, че ще трябва в отделни колонки ;), а не в отделни редове както е казал админа..
Поне аз не го виждам в отделни редове, как ще стане

Иначе дай да опростим малко това, което си написал :)
Имаш два варианта:
1. в едно поле
- лесно се добавят нови "екстри" за имотите (не се налага промяна на заявките към ДБ)
- товарене допълнително сървъра и усложняване на живота при търсенете и тн...
2. в много полета
при добавяне на някоя нова "екстра " ще трябва да променяш заявките

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

Затова аз избирам варианта с многото колонки.
Даже да добавиш нови екстри няма да е много трудно - ако си описал колинките, които ще се инсертват при добавяне на обявите, то при добавяне на нови колонки няма да се бъгне сайта. След това имаш само три файла в които трябва да едитнеш заявките - търсенето, добавянето и четенето на обявата.
 
Добре де.
Обърках. :)
редове колони.. той ме разбра.
Хубавото на чекбокса е че може да го запишеш с 0 и 1.
Точна дължина на полето 1 - tinyint
прави полето много-много бързо.

А това което ти sizif предлагаш е доста бавно . :)

Зависи от това колко записа ще има в таблицата.

Ако са 100 само може да си правиш всякакви експерименти но ако почнат да стават хиляди ще стане проблем.
 
admin каза:
Добре де.
Обърках. :)
редове колони.. той ме разбра.
Хубавото на чекбокса е че може да го запишеш с 0 и 1.
Точна дължина на полето 1 - tinyint
прави полето много-много бързо.

А това което ти sizif предлагаш е дота бавно . :)

Абе зависи от това колко записа ще има в таблицата.

Ако 100 само може да си правиш всякакви експерименти но ако почнат да стават хиляди ще стане проблем.
Увеличете...

аха, за това беше намигването :wink:
предполага, се че ще има много записи
 
Благодаря ви много и на двамата!

Правилно сте разбрали иначе обърканите ми въпроси... :)

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

По другото предложение: досега имам три падащи менюта, тях записвах с цифри, за чекбокса се колебаех (нали смятах в едно поле), но наистина 0 и 1 (за потвърждение), както препоръчвате, ми се струва по-удачно...
Това: tinyint сигурно е за тип на полето? Ще погледна още сега дали го има. Предполагам, че ако има стойност е 1, ако е празно - 0?

А иначе динамично ще се образува стойността само на падащо меню "градове", което вече функционира... Опциите за избор на чекбокса са статични, така че мисля да ги сложа в масив, от който да ги извличам, а после пак чрез него ще ги визуализирам...

Мислех си, че съм пред приключване, но се оказа, че възложителят има ново виждане :(

Благодаря много!

ПП: Досега релация м/у таблици не съм използвал (разглеждах няколко питания по въпроса, имаше едно такова и в последните постове), но за момента не ми се е налагало (или сигурно не съм разбрал, че ми трябва). За галерията, която правих (ако си спомняте, даже урок готвя :( ) се сещам къде можеше да го използвам, но тогава реших проблема с една допълнителна заявка...

Ако не ви затруднявам, можете ли да ми обясните как точно става и в какви ситуации (съвсем конкретно) се използва?

Още веднъж: благодаря за изчерпателните отговори!

Успешен ден/нощ!
 
Какво ще е това чудо?
Система за оферти ли?

Подсещаш ме, че съм имам един домейн запазен и трябва а го почвам да го развивам някак.
 
sizif каза:
Благодаря ви много и на двамата!

Правилно сте разбрали иначе обърканите ми въпроси... :)

Надявах се да има по-лесен начин от типа всичко в кюпа, но щом вие препоръчвате всяко по отделно, ще се вслушам!
Обикновено правя нещата по трудния начин и доста често се оказва, че има по-практични решения, затова въпроса ми беше за застраховка...
Увеличете...
няма по-лесен начин и подобре питай по често, ще си спестиш доста главоблъсканици.
sizif каза:
По другото предложение: досега имам три падащи менюта, тях записвах с цифри, за чекбокса се колебаех (нали смятах в едно поле), но наистина 0 и 1 (за потвърждение), както препоръчвате, ми се струва по-удачно...
Това: tinyint сигурно е за тип на полето? Ще погледна още сега дали го има. Предполагам, че ако има стойност е 1, ако е празно - 0?
Увеличете...
0 = не = FALSE
1 = да = TRUE
това е нещо като неписано правило :wink: и то не само в програмирането
TINYINT е типа на полето, приема само малки цели числа от 0 до 255
INT - приема само цели числа до 2 на степен 32
разликата е, че TINYINT заема само 1 байт, а INT 4 байта
sizif каза:
А иначе динамично ще се образува стойността само на падащо меню "градове", което вече функционира... Опциите за избор на чекбокса са статични, така че мисля да ги сложа в масив, от който да ги извличам, а после пак чрез него ще ги визуализирам...
Увеличете...
хм... няма ли да има избор на квартал?
ако не ти го искат, не се тормози. Но мисля, че е по добре да ги има.
Списък с крарталите можеш да си намериш наготово от разни сайтове
sizif каза:
Мислех си, че съм пред приключване, но се оказа, че възложителят има ново виждане :(
Увеличете...
И най-вероятно ще има още много нови виждания ;)
Най-добре е да им стане ясно, че новите виждания се заплащат допълнително и че удължават срока на изработка!!!
sizif каза:
Благодаря много!

ПП: Досега релация м/у таблици не съм използвал (разглеждах няколко питания по въпроса, имаше едно такова и в последните постове), но за момента не ми се е налагало (или сигурно не съм разбрал, че ми трябва). За галерията, която правих (ако си спомняте, даже урок готвя :( ) се сещам къде можеше да го използвам, но тогава реших проблема с една допълнителна заявка...

Ако не ви затруднявам, можете ли да ми обясните как точно става и в какви ситуации (съвсем конкретно) се използва?

Още веднъж: благодаря за изчерпателните отговори!

Успешен ден/нощ!
Увеличете...

Аз не мога да ти обясня накратно за базите данни. Не знам какви са ти финансовите възможности, но определено те съветвам да помислиш за закупуването на някоя книжка по-въпроса.
ДБ са хубаво нещо и трябва да им научиш възможностите и как да ги използваш. Останалото е лесно, пък и ти се отдава ;)

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

пп
imot.bg - засега е номер едно при сайтовете за имоти
imoti.net - се опитаха да ги изместят, но не успяха.

mirela.bg - разгледай сайтa, може да ти хареса нещо :) И един съвет, не предавайт толкова много ГЕТ променливи, като тях в търсачката. ИЕ се дъни.
 
admin каза:
Какво ще е това чудо?
Система за оферти ли?

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

сайт за имоти, я ми прочети горния пост, че да не ти пиша лично съобщение, че не ги обичам много много
 
И аз човъркам сайт за имоти.
Няма да е върха на сладоледа ама ще си е мой. :)
Даже съм си купил домейн oferti.net (ха-ха).

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

Сега се сетих за едно мнение от скоро .
Имаше линк към файл с всички градове и квартали точно за сайтове за имоти.

http://forum.joomla-bg.com/index.php?action=dlattach;topic=6711.0;attach=2914
 
admin мерси, и на мен ще ми е от полза за градовете, а за чековете, най-добре е всеки в отделен ред (колона)* да се записват.

* - приемайте го както искате "ред(колна)"
 
Благодаря! :)

Правя сайт за имоти, който ще е адресиран към външния пазар. Админ, ако помниш въпрса за заявката при търсене, за който ми помогна преди седмица, беше за същия сайт, мисля че бях писал...

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

За книга - когато мога да отделя време на РНР, напредвам прогресивно (този форум специално се оказа неочаквано добър помощник) - първия повече статичен, отколкото динамичен сайт правих (и не завърших :)) през август-септември...
Често се случва така, че докато избера книга, вече съм надскочил акцента в нея и ми трябва друга, а и нерядко трябва да се справям с изънредни разходи :( А и ми се ще да е книга, която да мога да ползвам за справочник. За РНР съм свалил няколко ръководства, които ме вкараха в езика, но темите за работата с БД не са добре развити и затова задавам може би странни въпроси...

Благодаря за връзките, Slavei! За много сериозни сайтове става дума... Ако ми кажеш как е организирано търсенето в третия (чекбоксове според региона) - златен си! :)

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

Като споменах хрумките на възложителя, сетих се че днешната идея е да има два реф-номера, единия ще си е както досега, другия изисква случайно число, пуснах въпроса в отделна тема.
Въпроса ми е може ли да се реши с някаква функция от работата с БД?

Още веднъж: благодаря, че следите темата!

Ползотворна нощ/ден!

ПП: нета ми тази нощ е скапан, докато успея да изпратя - пращате ми още нещо!

Благодаря!!
 
Админ!!
Къде ме вкарваш?! Не разбирам нищичко от XML! Тъкмо се бях поуспокоил, че съм почнал да поразбирам донякъде и изведнъж драматично ме приземяваш...

Ако не те мързи (само за теорията) и ако не задавам твърде глупави въпроси, може ли да обясниш, какво точно е RSS и какво точно заменя от стандартния код? И евентуално, мога ли да го използвам към кода, който съм писал досега - грозен ХТМЛ, раздвижван с РНР? И ако го използвам (отворих файла), какво грубо казано печеля?

ЕДИТ: НЕ ЧЕТА ВНИМАТЕЛНО, В ТЕМАТА Е НАПИСАНО :)

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

Онова, к най-много ме притеснява по "моя" сайт е не толкова кода, колкото как да го вкарам в търсачките, така че да излиза на що-годе поносимо място при търсенето, но ще му мсиля за това като дойде момента...
 
XML - RSS има програми който взимат кода.. и ти показват да кажеме новини, оферти и каквото се сетиш. може от един сайт на друг да се визуализира инфо с RSS
 
Ама няма какво толкова да му разбираш на xml-a.
Поне не на този етап.
Може да стане доста сложно ако решиш да ползваш всички възможности.

Просто си го представи като средство за съхраняване на информация.

Може примерно два сайта да си обменят информация чрез xml файл.
 
sizif каза:
Благодаря! :)

За книга - когато мога да отделя време на РНР, напредвам прогресивно (този форум специално се оказа неочаквано добър помощник) - първия повече статичен, отколкото динамичен сайт правих (и не завърших :)) през август-септември...
Често се случва така, че докато избера книга, вече съм надскочил акцента в нея и ми трябва друга, а и нерядко трябва да се справям с изънредни разходи :( А и ми се ще да е книга, която да мога да ползвам за справочник. За РНР съм свалил няколко ръководства, които ме вкараха в езика, но темите за работата с БД не са добре развити и затова задавам може би странни въпроси...

Благодаря за връзките, Slavei! За много сериозни сайтове става дума... Ако ми кажеш как е организирано търсенето в третия (чекбоксове според региона) - златен си! :)

Благодаря!!
Увеличете...

Не ми говори за извънредни разходи :(
Иначе за да минеш тънко, провери в книжарницата на ТУ-София (ако си от София) дали все продават все още една книжка "Научете сами SQL" Тя е в два тома, издадена през 98-ма година. Продаваха отделно двата тома и по-спомен първия том, който на теб ти трябва е 10-15 лв.

За чекбоксовете не те разбрах. На кое казваш регион? И в какъв смисъл как е организирано?
 
Здарвей, Slavei!

Имах предвид търсенето в треитя сайт: три скролиращи див-а (с чекбоксове) и падащи менюта за избор на регион. Щом се избере региона, излизат населените места в него...

Интересен ми е както Джскрипта, така и начина по който е организирана Бд... Не за сегашния сайт, а по принцип. Проекта за имотите трябва да приключа бързо... :(

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

Уж всичко, което трябва, мога да направя (и работи), но като започнах да "оптимизирам" кода (тръгнах от забележките ви с Админ за чекбоксовете и продължих да "зачиствам"), започнах да разбирам, че имам доста излишни операции и че тъпча БД с излишна информация :(

Сега съм свел полетата с низ до 4, всичко останало е инт или тининт, налага се обаче да направя "обща" заявка към две таблици:

Имам таблица за регионите с полета:

idr | name_r | zag_r | opis |

В таблица за обявите:

idg | ref | ... още полета... |regn | и т.н ...

Където стойността на regn е съответното idr на региона, в който се намира имота.

Досега записвах името на региона и никакъв проблем при листване или търсене, но оптимизирах БД и сега се налага по стойността на regn (= idr в другата таблица) да получа от другата таблица името на региона...

Как трябва да изглежда заявката за листване и за тръсене? А възможно ли е да се създаде връзка межу три таблици?

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

Благодаря предварително!

ПП: А за името на книгата - благодаря! Не живея в Сф от около година, но утре пътувам натам, така че ако остане време ще я потърся...
 
доколкото разбирам искаш да изведеш информация от 2 таблици ?
Първо ще ти го напиша кратко и ясно:

idr | name_r | zag_r | opis |

В таблица за обявите:

idg | ref | ... още полета... |regn | и т.н ..

SELECT tbl1.pole1 , tbl2.pole2 , tbl2.pole123 FROM tablica1 tbl1 , tablica2 tbl2 WHERE tbl1.pole1 = tbl2.pole2

сега и твоята заявка...
таблицата с полета idr | name_r | zag_r | opis | се казва regioni
а другата с полета idg | ref | regn | се казва obqvi

SELECT tbl1.idr, tbl1.name_r, tbl1.zag_r , tbl1.opis , tbl2.idg,tbl2.ref,tbl2.regn FROM regioni tbl1 , obqvi tbl2 WHERE tbl1.idr = tbl2.regn

общо взето на този принцип е.. може да добавиш Ordery by и DESC също и LIMIT 10 където 10 е колко резултата да покаже.

Общо взето ако нямам някоя фатална грешка това е :)
 
sizif каза:
Здарвей, Slavei!

Имах предвид търсенето в треитя сайт: три скролиращи див-а (с чекбоксове) и падащи менюта за избор на регион. Щом се избере региона, излизат населените места в него...
Увеличете...

Явно няма да намеря време да преборя мързата затова ще ти обясня набързо.

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

пхп-то няма нищо особено. Номера е в базата. Трябва да имаш допълнителна колонка в която да запишеш ид-то на града.
Да приемем, че имаш селект от който избираш града и при избора му, се листват кварталите.
Като избереш града, пускаш една заявка до таблицата с кварталите като за where условие слагаш да селектира само тези редове в колонката на които присъства ид-то на града, който е избран. В случая при мирела, има и допълнителна колонка, която съдържа ид-тата на групата квартали или общини... които съответно се пазят в друга таблица... това е :)
надявам се да си ме разбрал.

пп
това, че сайтовете, които ти дадох са големи, не означава, че не трябва да ги гледаш и да взимаш идеи от тях. Най малкото, можеш да видиш доста решения на проблеми с които тепърва ще се сблъскаш ;)
Пък и защо да не се бориш с тях??
 
Трябва да си влезнал или регистриран, за да отговориш тук.

Back
Горе