Comments 18
для хранения данных использовали (тут вы можете подумать MySQL\PostgreSQL\SQLite\MongoDB\Что-то-там-еще-но-обязательно-с-суффуиксом DB-иначе-пацаны-не-поймут, а вот и не угадали)… ммм… дайте подумать…
функции БД на PL\SQLА вот и угадали ;)
В общем — при подключении, в функции проверки данных аутентификации генерировалась временная таблица, в которой хранился ид пользователя.Эмэсэскуэльщик, быстро перековавшийся в ораклиста? У вас должно было быть очень весело…
И еще одна серьезная проблема — не формализованная схема хранения данных.Что такое «неформализованная схема» применительно к реляционной СУБД? Там внутри все очень даже формализовано.
Как и обещал ранее — рассказываю о хранении “любых полей” из JSON. Нет, они не хранились как строка в таблице. Они разбивались на key-value пары и хранились в отдельной таблице. Например, для пользователей было 2 таблицы — users, и users_data (string key, string value) — где собственно и хранились данные. Итогом такого подхода стало увеличение времени при сложных выборках из БД.По вашему описанию непонятно, что такое «хранение “любых полей” из JSON» и как оно потом используется, и детали реализации тоже не очень ясны, но судя по имеющейся информации — по факту это реализовано лучше, чем предлагаете вы. А причины тормозов выяснить не сложно — оракл в этом плане обладает очень хорошим инструментарием. Скорее всего, просто не было никого, кто умеет им пользоваться.
Т.е. мы сохраняем структуру вида a:«a data», b:«b_data», c:«c_data» для пользователя с id 123 и этому будут соответствовать 3 строки в users_data (опуская pk):
123, a, a_data
123, b, b_data
123, c, c_data
…
Тогда чтобы получить все данные для пользователя, надо выбирать по where user_id=123
У меня на работе в legacy коде одного продукта используется такой подход: есть дополнительно поле в каждой строке таблицы, в котором данные хранятся в двоичном serialized виде с признаками начала ключа и начала значения. Разумеется, это «листовые» данные, по ним не производится поиск.
Не формализованная схема — может я не совсем понятно выразился, и неверно подобрал определение. Смысл в следующем — есть некая сущность, пусть будет, скажем, входящее письмо, у которого есть следующие поля — «От кого»,«Кому»,«Куда», «Содержание», «Дата отправления», «Дата получения», «Доставил», «Получил». Для реализации схемы создавалось 2 таблицы — letters, и letters_data. В letters поля — id, from (fk users), to (fk users). Остальное в таблице letters_data, в которой есть 4 поля — id, letter_id, key_value, следовательно для хранения оставшихся полей будет 6 записей в letters_data, вместо того чтобы сделать alter table и добавить столбец.
Хранение любых полей json — передаем в структуре входящего письма кроме полей, означенных выше еще 1 поле, например «answer_on» (ответ на другое письмо, в поле по логике должен лежать id письма), это поле и залетает в letters_data седьмым.
Выяснить причины тормозов действительно несложно, но когда вам нужно будет, например получить все письма, отправленные за период, и принятые кем-то — начинается магия с кастами. Или, например, ссылочная целостность в данном случае тоже страдает.
Пример с письмами, конечно, очень условный.
Да и основная претензия к данной разработке такова, что архитектура представляет собой сборную солянку, чтобы поддерживать которую надо владеть php\python\js\plsql, это обстоятельство в условиях отсутствия документации на «черный ящик» — сулит определенные эротические похождения.
Думаю, таких историй у каждого в загашнике, кто проработал от 10 лет. У меня ощущение, что как минимум 95% существующего кода просто ужасно.
С одной стороны, существует мнение, что «плохой код — это тот, который написан не мной» (другими словами, не надо жаловаться, сами пишете не лучше, все субъективно). С другой стороны, я отношу себя к людям, считающим, что объективно плохой код существует и преобладает (сам тоже часто пишу плохой код, несмотря на все старания).
Ну вот как быть, например, с такими фактами, что большинство JS приложений, даже очень простых, непрерывно потребляют от 2 до 60 (при нормальной работе, в исключительных случаях доходит до 100 и более) процентов CPU. Какой-нибудь таймер на JS (для подсчета времени, затраченного на задачу) может запросто непрерывно съедать десятки процентов процессорного времени. Да, это не смертельно. Только вот ноутбук от батарейки работает значительно меньше, где-то раза в два, чем если не использовать ни кусочка JS кода.
Или вот типичные ошибки, которые многие повторяют из раза в раз. Например, при каждом изменении требований, тупо добавлять в код еще одно вложенное условие или цикл, вместо того, чтобы окинуть всю архитектуру в общем, и подумать, как лучше переработать код, чтобы он отвечал изменившемуся требованию. В итоге, получаются огромные классы или или методы или функции, в которых можно увидеть 4-5 вложенных условий, тогда как уже три уровня тяжело читать и понимать.
Вот хорошая эмоциональная статья о таком: https://www.stilldrinking.org/programming-sucks
На самом деле хороший подход реализовывать требования "в лоб". Но после реализации должна быть фаза рефакторинга. Ну или сначала провести рефакторинг под планирующуюся реализацию, а потом реализовывать, но это чревато:
- закопаться в рефакторинге, так и не выйдя на реализацию к дедлайну
- при реализации выявить, что план под который делался рефакторинг был неудачным, не учитывали какие-то нюансы.
Сделав сначала реализацию, можно спокойно заниматься рефакторингом, в крайнем случае не завершая его к дедлайну, ведь фича уже реализована. Просто заводим задачу на рефакторинг, а основную задачу сдаём.
«плохой код — это тот, который написан не мной»
Есть и такая крайность, хотя свои разработки никогда не возводил на пьедестал почета. Бомбит от подхода «у меня все настолько хорошо сделано что код выложил на порнохаб вместо гитхаба», особенно когда выясняется что разработка толком-то свою функцию не выполняет. Если разработка выполняет свое предназначение (пусть даже состоит из костылей) — лааадно, надо просто отрефакторить, это интересный процесс, а вот когда разработка представляет собой граблю — как-то грустненько становится.
История небольшого исследования легаси-кода