Как мнение: То, что можно продать, должно лежать в одной таблице и иметь свой id. То, что программистам лень/не удобно/долго добавлять множество свойств товара - это проблема программистов, а не структуры данных. Задача с множествами размеров, цветов и тд решается простым id_parent на себя саму. Это решает множество проблем при учёте товаров в бухгалтерии, экспорте, импорте и тп. Хранение же данных в json можно рассмотреть как вариант кеширования.
Я в своей системе сделал локальный сервер. Пользуюсь больше 5 лет, всякое бывало )) много раз перелазил через забор, т.к. ворота не открывались) но это все ерунда, ничего критичного. И вот я пришел к выводу, что без управления с инета можно спокойно пережить какое-то время, главное - продублировать функции через физические кнопки (у меня кнопки могут нажиматься от 1 до n - и выполняются определенные действия).
1.1. Для внутренней системы погружение в материал очень полезно. После приема на работу это отдельный курс по повышению квалификации :) Да и ссылку можно запомнить для будущего применения.. Для внешних клиентов это наоборот вредно (да и невозможно).
1.1. Для внешних клиентов это архи полезно, для работников же мотивирует их не учиться системно понимать работу, а бессистемно дергать инфу. (моё мнение)
Здесь согласен - интерактив, если он реально полезен, очень большое преимущество. С другой стороны и в wiki можно встроить скрипт по запуску чего-либо.
Еще стоит учесть, что создание и обслуживание подобного супербота гораздо более ресурсоемкая вещь, чем ведение wiki.
Можете ради интереса сформулировать чем выгодно отличается хорошо оформленная внутренняя wiki от такого супер бота? Ведь в конечном счёте у вас это просто вопрос поиска нужной информации.
Я Хабр просматриваю раз в 3 недели, трачу на это 10 минут, черпаю иногда очень интересное для работы, так что время на "чтение всяких статеек" окупается в степени :) Сериалы, кстати, не смотрю. И водку не пью (сообщаю, ибо предвкушаю ваш следующий аргумент :)
"Но не в этом дело" вы похоже пропустили, ну ладно. Сейчас мы дойдем до того, что ООП нужно для автодополнения в IDE. Я вот не программировал в IDE уже лет 15 - вот такая неказиста жизнь простого программиста :)
Ну и множество других вариантов как решить проблему. Но не в этом дело. Сохранение подразумевается по умолчанию.. не переписывать же сервер БД на клиенте :)
В случае отправки id сохранение в базе подразумевается в примерно 98% случаев ) Хотя конечно могут быть варианты. Но и с объектом тоже не так сложно - достаточно один раз ознакомиться с шаблоном проектирования
Да, класс это структура тех же функций, связанных по смыслу, но имеющие общие данные (чтобы не передавать в каждую контекст). Похоже автор в этом и соревновал два подхода )
Как заголовок вяжется с текстом?
Как мнение: То, что можно продать, должно лежать в одной таблице и иметь свой id. То, что программистам лень/не удобно/долго добавлять множество свойств товара - это проблема программистов, а не структуры данных. Задача с множествами размеров, цветов и тд решается простым id_parent на себя саму. Это решает множество проблем при учёте товаров в бухгалтерии, экспорте, импорте и тп. Хранение же данных в json можно рассмотреть как вариант кеширования.
Не думали забросить программирование и просто стать писателем? У вас отлично получается, можно попробовать что-то художественное )
А потом искать фромы на страницах справа? )
Я в своей системе сделал локальный сервер. Пользуюсь больше 5 лет, всякое бывало )) много раз перелазил через забор, т.к. ворота не открывались) но это все ерунда, ничего критичного. И вот я пришел к выводу, что без управления с инета можно спокойно пережить какое-то время, главное - продублировать функции через физические кнопки (у меня кнопки могут нажиматься от 1 до n - и выполняются определенные действия).
1.1. Для внутренней системы погружение в материал очень полезно. После приема на работу это отдельный курс по повышению квалификации :) Да и ссылку можно запомнить для будущего применения.. Для внешних клиентов это наоборот вредно (да и невозможно).
1.1. Для внешних клиентов это архи полезно, для работников же мотивирует их не учиться системно понимать работу, а бессистемно дергать инфу. (моё мнение)
Здесь согласен - интерактив, если он реально полезен, очень большое преимущество. С другой стороны и в wiki можно встроить скрипт по запуску чего-либо.
Еще стоит учесть, что создание и обслуживание подобного супербота гораздо более ресурсоемкая вещь, чем ведение wiki.
Можете ради интереса сформулировать чем выгодно отличается хорошо оформленная внутренняя wiki от такого супер бота? Ведь в конечном счёте у вас это просто вопрос поиска нужной информации.
Похоже стёб никто не понял :)
Я Хабр просматриваю раз в 3 недели, трачу на это 10 минут, черпаю иногда очень интересное для работы, так что время на "чтение всяких статеек" окупается в степени :) Сериалы, кстати, не смотрю. И водку не пью (сообщаю, ибо предвкушаю ваш следующий аргумент :)
Очень круто, но и очень жалко время автора на это :)
Если вы скажете что-то типа "я не запоминаю синтаксис, а решаю задачи" и после этого вас выгонят, то собеседование для вас прошло успешно )
Это к вопросу фич - вы просто делаете работу или достигаете какой-то цели. Нужно было сделать какой-то график - работа выполнена красиво )
Ок, уволите меня, если вдруг станете моим начальником :)
"Но не в этом дело" вы похоже пропустили, ну ладно. Сейчас мы дойдем до того, что ООП нужно для автодополнения в IDE. Я вот не программировал в IDE уже лет 15 - вот такая неказиста жизнь простого программиста :)
article_set($id_article, ["meta"=>'', "title"=>'', "body"=>'']);
Ну и множество других вариантов как решить проблему. Но не в этом дело. Сохранение подразумевается по умолчанию.. не переписывать же сервер БД на клиенте :)
В случае отправки id сохранение в базе подразумевается в примерно 98% случаев ) Хотя конечно могут быть варианты. Но и с объектом тоже не так сложно - достаточно один раз ознакомиться с шаблоном проектирования
Да, класс это структура тех же функций, связанных по смыслу, но имеющие общие данные (чтобы не передавать в каждую контекст). Похоже автор в этом и соревновал два подхода )
Судить здесь можно либо материал, либо автора. Первое - сложно и долго, второе проще простого, особенно на аналогиях.
Скорее всего не будет там репутационного урона - заказы как были, так и продолжат поступать, это же НЕ конкурентная среда.
Видимо да, кто-то думает, что это реальный искусственный интеллект, а не умелая работа программистов )