草庐IT

坏主意

全部标签

sql - 对于单个应用程序来说,拥有多个 SQL 数据库是个坏主意吗?

我正在设计一个iOS应用程序,并决定将持久性要求分离到三个独立的SQL数据库中。静态数据-只读但从外部来源下载客户端请求数据-客户端排队发送到外部源的数据应用程序元数据-保存有关其他两个数据库和整个应用程序状态的元信息。这可能是但不限于表/应用程序版本信息、应用程序上次与外部源通信的时间。这种分离背后的想法是第一个数据库是有效可替换的,第二个是事务源,而元信息不应增长。这种方法有什么注意事项吗,当然我知道我不能加入每个,尽管我不打算这样做。 最佳答案 当然,这种方法本身并没有什么“坏”之处。事实上,这通常是个好主意,在你的情况下听起

android - 使用 REST Api 的移动应用程序开发计划是个好主意吗?

我是移动原生应用开发的新手。但我熟悉网络应用程序开发。我打算先开发iPhoneNativeApp,然后再开发AndroidNativeApp。为了尽量减少工作量,我的计划是为我的应用开发RESTAPI。API服务器将处理数据库CRUD和session,以便NativeApp调用以抽象方式从数据库获取数据。这样我的iOS、Android等native应用程序就可以使用这些RESTAPI读取和写入照片、文本、LatLng等我不确定这是开发native应用程序的推荐方法。也许与native应用程序和数据库直接通信会有更好的性能,但我担心在所有其他native应用程序版本中开发逻辑。

java - 使用 Spring AOP 记录是个好主意吗?

我目前正在阅读Spring,其中一个用于使用AOP的示例是记录方法调用的开始和结束。我还了解到使用AOP会影响性能。对于这种类型的日志记录,使用SpringAOP是个好主意吗?我的理解是Spring使用DynamicAOP是否会更好地为这种类型的AOP使用StaticAOP(如AspectJ)。目前我工作的公司的编码政策需要大量的日志记录,我想减少我必须编写的日志记录代码的数量并提高我的代码的可读性。我是不是找错树了? 最佳答案 我使用SpringAOP来实现日志记录,所以我分享一下我的观察:性能影响不够,小于日志本身的影响在Spr

java - 使用 Spring AOP 记录是个好主意吗?

我目前正在阅读Spring,其中一个用于使用AOP的示例是记录方法调用的开始和结束。我还了解到使用AOP会影响性能。对于这种类型的日志记录,使用SpringAOP是个好主意吗?我的理解是Spring使用DynamicAOP是否会更好地为这种类型的AOP使用StaticAOP(如AspectJ)。目前我工作的公司的编码政策需要大量的日志记录,我想减少我必须编写的日志记录代码的数量并提高我的代码的可读性。我是不是找错树了? 最佳答案 我使用SpringAOP来实现日志记录,所以我分享一下我的观察:性能影响不够,小于日志本身的影响在Spr

ios - 通过隐藏标签栏自定义 UITabBarController。馊主意 ?

我正在研究自定义UITabBarController的方法.自定义包括每个条形项的自定义图像和一个“凸起”的中央按钮项。我知道Apple不建议对UITabBarController进行子类化,并且我找到了一些示例来处理这个问题,方法是从头开始编写一个模仿默认行为的新组件。但我觉得不值得放弃默认提供的功能,因为我只想给组件“蒙皮”。我的想法是隐藏标签栏并在标签栏顶部放置一些自定义按钮,这些按钮将调用tabbarcontroller.selectedIndex=按下时。这是个坏主意吗?我没有看到这有任何缺点,但想问问是否有任何其他简单的方法可以做到这一点。 最佳

hadoop - 从 S3 读取超过 500GB 的数据并将 400GB 输出保存到 S3 是个好主意吗?

我的MR作业从AWSS3读取500GB数据,同时将中间数据保存在S3中,并将reducer的输出(大约400GB)写入S3,这是一个好的设计吗?还有其他更便宜、更稳定的解决方案吗?谢谢! 最佳答案 我们的ETL作业在AWS中运行。我们使用Oozie进行工作流管理。当您在EMR(ElasticMapReduce)中运行时,您可以选择写入s3或本地HDFS。将数据存储在s3或HDFS中的决定取决于多种因素,例如:数据的性质:临时(使用HDFS)或永久(使用s3)成本:存储在s3中会花费您一些美分/美元带宽:当您将数据上传到s3时,您会消

hadoop - 在 Hadoop 中,按日期对表进行分区是个坏主意吗?

我正在阅读罗伯托在以下帖子中给出的答案。WhatisthedifferencebetweenpartitioningandbucketingatableinHive?似乎按日期对数据进行分区(如果我的数据每天都来)不是一个好主意,因为它最终会在HDFS中创建许多目录和文件,并且会降低查询的整体性能?如果我有业务需求,需要更频繁地使用日期来查询数据,我该怎么办? 最佳答案 使用日期作为分区绝对没有错。事实上,它是最常用的分区值之一。每年365个额外的目录不会对集群的性能产生任何影响。至于改变文件的数量:如果你每天都在摄取数据,那么无论

php - 每次登录更新散列盐是个好主意吗?

我想做一个安全的网站。每次用户登录时更新密码salt是个好主意吗?编辑:我还使用了硬编码的全局盐。 最佳答案 不,这根本没有意义。加盐哈希的目的是使它们唯一,即使原始密码相同。这避免了例如彩虹表攻击或在哈希足以登录的另一个网站上重新使用被盗的哈希(发生在错误的记住我实现中)。假设攻击者从您的数据库中获取了存储的密码哈希值。这通常意味着他知道盐和最终哈希值。现在他已经可以暴力破解这个单一密码了。假设没有冲突,当暴力攻击成功时,他最终会得到用户的实际密码。并且无论此时使用什么盐,它都会起作用。有关加盐的更多信息,我建议您阅读thisex

php - 在 Laravel 中使用自动 Controller 路由是个坏主意

我要从CodeIgniter转到Laravel。那么,对所有Controller使用自动路由是个坏主意吗?Route::controller(Controller::detect());我应该使用它来代替在routes.php中创建路由吗? 最佳答案 是的,这很糟糕。Controller::detect()实际上在Laravel4中不存在,因为它有点损坏。detect()将遍历您的文件系统并返回Controller文件,但这是个坏主意,因为您定义路由的顺序很重要。如果您有任何嵌套Controller,您会发现这很容易崩溃。detec

php - 标准化的返回值——这是好主意还是坏主意

我在PHP中工作(但在这种情况下我认为编程语言并不重要),在我的类方法中我通常会遇到以下情况:方法必须返回true或false方法必须返回true或错误信息方法必须返回true+成功消息或false+错误消息方法必须返回true+成功结果(对象、数组等)或false方法必须返回true+成功结果(对象、数组等)或false+错误消息等等我的问题是,当我在我的代码中的某处使用此类方法时,我总是必须回到类中,并检查实际返回的方法是什么:简单地true或false、true或错误信息等标准化返回值是个好主意吗?如果是,如何?我的想法是:如果函数必须返回true或false则只需返回true或