Евгений: да FanatPHP тут такой... свое мнение, ничем не подкрепленное, любит выставлять как истину в последней инстанции )) в каждой ж... бочке затычка. все у него неправы - один он дартаньян )
> это на скорость никак не влияет?
зависит от реализации логики. я с RoR не знаком.
Вы можете создавать таблицу Комментариев для группы сущностей, которые будут однотипны. Разграничить можно составным ключом.
Еще плюсом будет то, что одна таблица Комментариев не будет пыхтеть на все подсистемы. Будет своего рода распараллеливание запросов. И не будет все в одной "свалке", а все логично и красиво.
tarasverq: что быстрее будет сказать сложно. надо проверить оба варианта. кода писать не много придется.
я не знаю в каком виде данные у вас изначально. Я предполагаю что данные уже лежат в каком-то экземпляре класса C#. Вообще сериализация в XML занимает достаточно мало времени. Но есть ограничения на длину параметра, который будет передаваться в хранимку. Ограничение можно обойти если сохранить все данные в XML файл, на сервере БД, - и передать в БД ссылку на этот файл.
Проще всего сделать загрузку данных во временную таблицу. Только сам SaveChanges нужно делать в самом конце. а не после каждой записи.
зачем вообще вытягивать данные из БД и делать логику в приложении/памяти? проще отдать все данные в БД пакетно - и написать оптимальный SQL запрос на пересечение множеств данных.
keslo: если вы делали бекап данных в одной кодировке, а восстанавливали в другой - то такое могло произойти. Вообще старайтесь все делать в UTF-8. База, бекапы, код html и сам редактор html - чтобы все было в одной кодировке. Тогда проблем не будет.
Arti Markelov: хм... странно. сам не пользуюсь sublime text. может вам стоит написать Issue разработчикам на гитхаб или где они размещаются. Другую сборку-версию попробуйте. Может конечно какой из плагинов приводит к ошибке. Надо смотреть логи краша.
> А почему вы боитесь открывать алгоритмы шифрования? Это уже подозрительно.
раскрывать сам алгоритм, длину ключа, соль - это все не хотелось бы раскрывать.
Допустим с алгоритмом и схемой шифрования (все делать на стороне клиента) - понятно.
У меня вопрос в другом: я должен первым убеждать что все секъюрно, расжевывать до регистрации и убеждать всех в безопасности? или нужно запускаться как есть - и если что пусть эксперты ковыряют логи JS, смотрят что отдает браузер и т.д. Кто инициатор, так скажем.
Алексей Маслов: значит вы слепой. еще раз читайте что я написал выше:
1. "БД использовать как хранение результатов сравнения". "хранить в одной таблице"
2. "Сравнение надо делать на temp таблицах, в памяти" - измените таблицу на временную, с той же структурой. а результат потом кладите в основную таблицу.
Алексей Маслов: хранить в одной таблице как минимум. и не дублировать одинаковую информацию.
т.е. для задачи сравнения 2х файлов - вы вначале загружаете оба файла в БД и потом хотите средствами СУБД получить результат сравнения? ) Как минимум это идиотизм.
3 000 000 записей - и вы хотите закинуть туда свои 100 записей и потом сделать выборку на 3 000 100 записях чтобы сравнить 100 ? ))
Сравнение надо делать на temp таблицах, в памяти. А БД использовать как хранение результатов сравнения.
Про что я и говорил - люди не понимают архитектуры. Выдумывают костыли.
OnYourLips: если грамотно будут расставлены индексы и нормальное железо - то база будет выдавать на лету запросы. проблем с EAV нет, если только люди не умеют его готовить.
опять же - я написал Вариант 1 - делать через NoSQL.
подключить elasticsearch опять же. только архитектура будет та же. Возможно PARAMVALUES убрать можно будет. И хранить значение сразу в CARSPARAMS.
иногда хочется отправить Вас обратно в ВУЗ на уроки СУБД.
CARS (.... ) - многоточие это остальные ваши поля, я не знаю какие, ссылки на владельца, профиль пользователя. или еще что. Они могут меняться, кроме car_id.
PARAMSNAMES - да, справочник всех возможных Названий параметров. Можно еще добавить поле которое будет указывать на обязательность наличия в CARS, я другие поля не указываю - потому что это будет сбивать с толку, я пишу вашу конкретную задачу.
PARAMVALUES - аналогичен PARAMSNAMES - но тут хранятся Значения параметров.
CARSPARAMS (cparam_id, p_pname, p_pvalue, p_car_id) - я тут все расписал и разжевал. Научитесь читать.
