Почитал. В вашем "тут" вообще ни разу нет отсылки к статьям, что довольно странно для автора, называющего себя юристом.
В ГК вижу две статьи, подходящие к делу:
1301, от которой отталкивался автор (про то, что штраф за нарушение исключительных прав - от десяти тысяч до пяти миллионов, причем, замечу, это максимальный штраф за вообще любое преступление против исключительных прав)
и 1272, которая гласит:
Если оригинал или экземпляры произведения правомерно введены в гражданский оборот на территории Российской Федерации путем их продажи или иного отчуждения, дальнейшее распространение оригинала или экземпляров произведения допускается без согласия правообладателя и без выплаты ему вознаграждения
Никаких оснований считать копирование книги нарушением исключительных прав, кроме грозного запрета в договоре, который вообще-то должен опираться на какую-то правовую норму, я не обнаружил.
Но я не юрист.
Acaunt, вообще-то ко всем выше перечисленным аргументам о читаемости имеет смысл добавить еще один.
Отдельные функции searchInt / searchString в данном случае практически не увеличат код, но избавят и пишущего, и читающего от необходимости разбираться в шаблонах вовсе.
Мастурбация с датами путем замен и регулярок всегда рано или поздно приводит к граблям.
Единственный надежный способ работы с датами - это приведение их к таймштампу (разобрав ту хрень, которая у вас на входе) и использование встроенных функций для форматирования того, что уже точно является датой.
[ERROR] InnoDB: The innodb_system data file 'ibdata1' must be writable
Нет доступа к файлам БД на запись. Однако они, похоже, существуют.
Стоит посмотреть, какие права выставлены у этих файлов и какому пользователю они принадлежат.
Метод ничего никуда не печатает, а только возвращает строку. Не вводите читающего в заблуждение.
Название toString, например, более уместно.
Или serialize - в зависимости от того, для чего делается приведение к строке.
Наконец, если метод собирает урл, как написано в комментарии - почему не назвать его buildUrl?
Heinemann, БД на сайтах в основном служат для выдачи одной и той же информации каждому посетителю.
Они оптимизированы под то, чтобы быстро обрабатывать простые запросы и кэшировать их результаты, чтобы не перетряхивать данные снова и снова, а быстро отдавать уже готовый ответ на тот же самый запрос, если данные за это время все равно не менялись.
Делая сложные запросы и смешивая данные, которые меняются редко, с теми, которые постоянно актуализируются, вы только ломаете эту систему.
упаковать в один запрос к бд и получить ответ одной таблицей
Чтобы напрячь БД одним фильдеперсовым запросом вместо нескольких примитивных?
Например, запрос на общее количество постов между добавлением этих постов вообще не будет читать таблицу, сразу отдавая значение из кэша.
Выстраивание многоэтажных конструкций на SQL - это очень увлекательно, но это нечто противоположное оптимизации.
Таблицы - это не данные, это хаос.
Чтобы что-то искать, нужна структура.
А эти Ёксели с тем же успехом можно просто перегнать в CSV и делать тупой текстовый поиск по той номенклатуре.
Ситуация поменялась, но не насчет крестовиков-недоучек.
Они как два года назад никому не были нужны, так и дальше никому не понадобятся.
Хочется набираться опыта без опыта - стоит смотреть на веб-стек, там галеры и есть шанс.
Denis Izmailov, самый очевидный вариант - хранить тот аккаунт, который вы все равно раздаете с программой, на том самом сервере, к которому он будет обращаться по API. Так вы и устраните необходимость хранить что-то в программе, и сохраните контроль над тем, кто этот доступ получит.
В ГК вижу две статьи, подходящие к делу:
1301, от которой отталкивался автор (про то, что штраф за нарушение исключительных прав - от десяти тысяч до пяти миллионов, причем, замечу, это максимальный штраф за вообще любое преступление против исключительных прав)
и 1272, которая гласит:
Никаких оснований считать копирование книги нарушением исключительных прав, кроме грозного запрета в договоре, который вообще-то должен опираться на какую-то правовую норму, я не обнаружил.
Но я не юрист.