Влад, ещё как имеет.
И что значит "какой смысл применять isset"? Вы сами его и применяете. Только по-дурацки.
И кроме этого проверяете свои переменные на пустоту два раза.
if (!empty($_POST["name"])) - здесь вы проверяете переменную на существование (isset)и не-пустоту.
А потом еще раз на не-пустоту, вот здесь if ($name and $phone and $message)
А ProjectSoft в своем примере предлагает вам сделать по-другому: сначала проверить на существование, и присвоить пустое значение, если переменная не существует.
А потом проверять на пустоту.
Это более логичное поведение в общем случае
Но в данном случае проверка на isset не нужна. В вашем случае элемента массива $_POST с ключом 'name' может не существовать только если запрос был сделан не методом POST или если в форме нет поля ввода с таким именем. Оба этих случая являются форс-мажорными, и вам как раз полезно будет видеть ошибку, которую напишет в этом случае РНР.
В этом ответе написана чушь, непонятно, откуда ему столько плюсиков насовали. назначение Эластика - это делать быстрый поиск
Структурированные ли при этом данные, и откуда их брать - вопрос перпендикулярный.
Я правильно понимаю, что вы студент, который в гробу видел все эти скрипты, и пишете только чтобы препод отвязался?
Если так, то напишите сразу целиком задание, а не спрашивайте в день по чайной ложке
Дмитрий, на самом деле поможет конечно. Перебрать из индекса всяко быстрее, чем перебирать с диска. Но перебор всего индекса конечно тоже занятие так себе, когда можно бинарным поиском за пару хопов найти нужное значение.
Стоило написать, что именно в этом коде "грязно". иначе это просто бессмысленное сотрясение воздуха
Плюс если бы в реальном коде была опечатка с $phon, то тогда бы и заполненная форма не отправлялась
ProjectSoft, Пишите чётче. при таком построении фразы рекомендация использовать isset выглядит как рекомендация по решению проблемы.
С нормальным объяснением это стоит написать в виде ответа
Вот это и надо было писать в вопросе. А не "одна таблица по типу eav".
Для решения этой задачи никаких хитровыдуманных решений не нужно. Структура базы данных от организационной структуры компании не зависит.
"Будет добавляться в процессе эксплуатации без участия программиста" - это блажь.
Но если прямо так хочется мазохизма, то поставьте им битрикс
КАКОЙ ЗАДАЧИ?
Вы не привели в своем вопросе никакой задачи.
"унифицированная база данных, в которую бы поместилось все-все бизнес-сущности проекта" - это не задача, а бредовая попытка решения. Саму же задачу вы не удосужились здесь описать.
Вот поэтому их и не надо добавлять!