я так понимаю, вам достался проект на PHP, код, но вы не шарите совершенно.
1. id - уникальный идентификатор. он определяет одну и только одну запись в таблице.
2. что значит "чтобы он делал множественную запись" ?
если вам надо обновить много Юзеров, то надо менять WHERE id='$form_id'
на другое условие, какое именно - решать вам.
Неизвестно количество пользователей и количество вот таких строк и как часто он будет заходить на страницу и жмакать кнопку.
но можно попробовать сформировать некий список (Таблица М:М между Юзерами и Вашей_таблицей) заранее, случайно распределенных записей для каждого конкретного пользователя, и выдавать ему в первый раз 1ю строку, после Клика - менять текущую позицию Юзера, сдвигая ее вниз на одну. Если дошел до конца списка - менять на первую, вероятно, или генерить новый список.
1. Предлагаю сразу начать реализовывать серверное API или серверную часть. пока нимальный набор методов, необходимых дял декстоп приложения
2. Обычно схема с получением уведомлений делается так:
- ваша CRM должна уметь слать веб-хуки на событие "Добавлен Новый Пользователь", адрес указываете уже вашего серверного метода API
- событие уже обрабатывается в APIшке и тут могут варианты доставки на приложение
-- или приложение соединяется по сокету, постоянное соединение (это если пользователей мало)
-- или ваше десктоп приложение будет переодически, раз в 5 сек, например, опрашивать APIшку на предмет новых событий (это если пользователей много)
про вебхуки, сокеты можно почитать в гугле. там ничего супер сложного нет.
SELECT M.surname, M.name FROM gazeta.tbl_gazeta_members as M
JOIN gazeta.tbl_gazeta_members_phone as P ON P.id = M.iden
WHERE P.phone LIKE '%некий номер телефона%';
1. Лучше всего подключить сервис комментариев, например - HyperComments
2. Если же все же вы рискнули делать свой велосипед - то рекомендую делать 3 таблицы!
объясню почему :
- комментарии для страниц могут содержать цитату из страницы или какую-другую ссылку. для блогов тоже такое может быть - а для фото такого нет!
- комментарии для фото могут иметь рейтинг от 0 до 10. а страница и блог могут и не иметь.
- и таких ньюансов может быть много, замучаетесь заполнять на 1/3 таблицу. а 2/3 будут пустые столбцы.
кароче это разные сущности - и лучше в БД их развести по отдельным таблицам. Тогда никаких подводных камней не будет!
Архитектура БД facepalm.
Про нормализацию вообще не слышали походу.
Вначале создадут БД в стиле "и так сойдет". Заполнят ее на over9000 записей и потом жалуются по Интернетам - почему у них все тормозит и запросы не работают.
неужели сейчас так учат программистов? или это самоучки на Фрилансе натаскались такое говно делать?
PARAMSNAMES что-то вроде справочника, который будет заполняться разработчиком.
PARAMVALUES - справочник который будет наполняться пользователем в процессе набивки в inputs. c последующим использованием в будущем - список вариантов выбираться будет. или добавляться новое уникальное значение.
CARSPARAMS - список всего всего по конкретному авто.
Лучше реализовать хранение друзей не через связи-ключи в другой таблице - а через хранение LIST (любой другой набор) в XML | JSON формате в самой записи.
пример
userid name friendlist requestfriendlist subscrybefriendlist
1111 Ivan {2222, 3333} {4444} {}
2222 Sergey {1111, 3333} {} {4444}
3333 Olga {1111, 2222} {4444} {}
4444 Max {} {2222} {3333, 1111}
в friendlist - хранить подтвержденных друзей.
в requestfriendlist - хранить запросы друзей.
в subscrybefriendlist - подписчиков и т.д.
в коде делать связи на основе списков.
Удобно сериализовать данные и удобно ими оперировать. Перебрасывать из одного списка в другой.
разберитесь в предметной области (уничерситеты-факультеты) вначале - а потом приступайте к созданию таблиц в БД. в предметной области должна быть четкие условия существования одних факультетов в разных университетах.
хотя в жизни таких не встречал.
обычно Университеты (1 - *) Факультеты (1 - *) Специальности (1 - *) Группы
а вот Студенты могут учиться в нескольких группах, поэтому будет так - Группы (1 - *) (* - 1) Студенты.
вариант 1:
через phpMyAdmin например, таблицы - Анализ таблицы. Получить список кривых таблиц.
сменить кодировку на UTF-8 (и заодно в CMS сделать UTF-8 по умолчанию) для конкретных таблиц.
вариант 2:
Дампер вам в помощь: Sypex Dumper
делаем бекап с define('CHARSET', 'auto')
разворачиваем бекап с define('RESTORE_CHARSET', 'forced->utf8')
должно сработать.
Ответ написан
Комментировать
Комментировать
Оценили как «Нравится»
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
