Ребят, вы это серьезно? Надеюсь, вы сейчас дико тролите или просто прикалываетесь. Задача выполнена не та, что ставилась, да и то, что сделано - работает с ошибками ... какие придирки, какой синтаксис?
Если вам требуется подобный функционал - скорее всего, у вас что-то не так в логике приложения, можете описать задачу, в которой такое понадобилось? А то я как-то теряюсь в догадках, зачем подобное понадобилось.
Отображение объектов - это не часть объекта, это совсем другой слой в рамках MVC. У тебя должен быть отдельный класс/функция/набор классов, который занимается отображением объектов (если совсем сложно - то это будет фабрика, которая в зависимости от полученного объекта данных будет строить форму), но вариант с тупой шаблонизацией html - вполне себе ок вариант
Он и не вернется, просто увидев логическую ошибку,программист не стал копаться в твоем коде
Цитата:
Аргумент передается в конструктор класса.
А это важно? Я не вижу ни слово про конструкторы в тз
Цитата:
при описанном тобой подходе, когда не сохраняется состояние, вероятность возврата рандомна.
Когда работаешь с вероятностями (а в коэффициентах именно она), странно жаловаться на не абсолютные значения. При единичном запуске твоя функция ведет себя совсем не по тз
Требование 1
- на вход подается массив указанного формата,
У тебя на вход в функцию ничего не передается.
ТЗ не выполнено, это задание не засчитал бы и я
Что хотели от тебя: Что бы в одной функции, на основании переданной вероятности было принято решение, какой элемент массива вернуть (другими словами, составить функцию, которая бы с помощью генератора случайных чисел и полученных коэффициентов, отдала бы 1 ключ из тех, что получила) Ее можно вызвать 1 раз, 100 или 1000 000 - она работала бы одинаково, у тебя же хранится состояние (количество вызовов), от которого меняется вероятность выпадения того или иного ключа, а этого быть не должно
i_category_store_top - ненужный ключ, его можно смело удалить
Конструкция
SELECT
appId,
count(appId) cnt,
....
GROUP BY appId,
мне вообще не понятна, что вы хотите при этом получить?
скиньте дамп строк в 100к что бы статистику примерную видеть (Добавление)
GROUP BY DATE_FORMAT(created, "%Y.%m.%d %H:00") Этот запрос сразу отрубает у вас работу с индексами.
Now () в условии из первого запроса убивает всю работу с кэшами
Что бы решить эти проблемы - организуйте доп поле системное, которое будет хранить уже обработанную DATE_FORMAT(created, "%Y.%m.%d %H:00") строку, либо ее хэш (если коллизии для вас не критичны), а из условий уберите now(), заменив их полученными в php готовыми значениями
Знакомый, далекий от айти загорелся научиться верстать, но не знает, с чего начать. Если знаете хорошие ресурсы - буду благодарен
ps
интересуют ссылки, которые вы сами читали и вам понравились, не стоит кидать популярную литературу
Это мне не подходит, хотелось бы написать ядро самому.
Это прекрасно В любом случае вам нужно нормализовывать исходный поисковый текст (есть много алгоритмов - гуглите), так же вам нужно индексировать ваши статьи (опять же нормализованные). И искать по этому индексу. Алгоритмов куча - начиная от триграмм (монограмм и что вам больше подходит - смотрите сами) и заканчивая фонетическими разборами. Я с трудом представляю, как вы будете это делать, задавая те вопросы, которые задаете (мне кажется, что не доросли вы еще до подобных задач). Сфинкс - это и есть тулза, которая берет на себя задачу по индексированию текстов и поиску по этим индексам. Если не можете использовать сфинкс (люсину) - смотрите в сторону уже упомянутой зендовской библиотеки, либо воспользуйтесь тем, что дают базы данных для полнотекстового поиска.
ps
Если вы боитесь недополучить интересных задач - не бойтесь, их там хватит за глаза и без самописного индексатора.
Скажите, почему использование хранимых процедур в данной системе плохо?
1. Бизнес-логика размазывается по 2 системам - часть кода у вас на php (обращение к внешним системам, валидации, обработки ошибок, логи и тд), часть в хранимых процедурах (списание, смена статусов - все, что внутри транзакции)
2. Если вам придется шардировать данные, как на хранимых процедурах вы организуете работу с несколькими удаленными серверами?
3. Сложно организовать детальное логирование происходящего в системе, обработку разных типов ошибок. А вы работаете с деньгами, все ходы должны быть записаны
4. Вы не сможете некритичные данные получать с ro-реплик, разгружая rw-базу.
Наверняка, есть еще, но это что первое в голову сразу приходит